[GRECLIPSE-1828] groovy-eclipse-batch 2.4 Created: 23/Mar/15  Updated: 26/Mar/15  Resolved: 26/Mar/15

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.9.1.Release
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Christopher Smith Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Eclipse now has compiler support for Groovy 2.4, but the groovy-eclipse-batch dependency is not available in a standalone Maven build.



 Comments   
Comment by Kris De Volder [ 25/Mar/15 ]

I have just built and staged

groovy-eclipse-compiler 2.9.2-01
groovy-eclipse-batch 2.4.3-01

These are available from codehaus staging repo:
https://nexus.codehaus.org/content/groups/staging/

I'll leave it there for a couple of days so if someone could test them out a little before I press the button to promote them to maven central that would be great.

Thanks,

Kris

Comment by Kris De Volder [ 26/Mar/15 ]

Artefacts released to maven central closing





[GRECLIPSE-1818] Broken update site Created: 18/Jan/15  Updated: 22/Jan/15  Resolved: 22/Jan/15

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eugene ?rokopiev Assignee: Kris De Volder
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It is not possible to download something from update sites - content length is 1 and content is 0:

$ curl -v dist.springsource.org/release/GRECLIPSE/e4.3/

  • Adding handle: conn: 0x659510
  • Adding handle: send: 0
  • Adding handle: recv: 0
  • Curl_addHandleToPipeline: length: 1
  • - Conn 0 (0x659510) send_pipe: 1, recv_pipe: 0
  • About to connect() to dist.springsource.org port 80 (#0)
  • Trying 54.231.34.9...
  • Connected to dist.springsource.org (54.231.34.9) port 80 (#0)
    > GET /release/GRECLIPSE/e4.3/ HTTP/1.1
    > User-Agent: curl/7.31.0-DEV
    > Host: dist.springsource.org
    > Accept: /
    >
    < HTTP/1.1 200 OK
    < x-amz-id-2: xUD7oV+T1GFqOVmBEnYeHAfUnGO4La59nBoaVptxiWpQO9iSEEDpbbXj5Z+RBJ1Y
    < x-amz-request-id: 5BE20A022DF9DC4E
    < Date: Mon, 19 Jan 2015 05:31:47 GMT
    < Last-Modified: Mon, 17 Nov 2014 10:40:29 GMT
    < ETag: "cfcd208495d565ef66e7dff9f98764da"
    < Accept-Ranges: bytes
    < Content-Type: binary/octet-stream
    < Content-Length: 1
  • Server AmazonS3 is not blacklisted
    < Server: AmazonS3
    <
  • Connection #0 to host dist.springsource.org left intact
    0

In Firefox and Chrome ans with other eclipse versions result is the same.



 Comments   
Comment by Kris De Volder [ 22/Jan/15 ]

The update site works for me. I pasted the url into Eclipse's 'Install new software' dialog and it looks fine.

You can't download something from http://dist.springsource.org/release/GRECLIPSE/e4.3

Because it is not a website but an Eclipse update site. Eclipse knows how to access certain urls below that path to determine what stuff is there. But you can't point your browser at that url directly, or use a curl request to read something from it.

A better test than your curl request is, for example this:

kdvolder@lebun:~/git/groovy-eclipse$ curl dist.springsource.org/release/GRECLIPSE/e4.3/compositeContent.xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<repository name="Groovy Eclipse Latest Release for Eclipse e4.3" type="org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository" version="1.0.0">
  <properties size="1">
    <property name="p2.timestamp" value="1416218899394"/>
  </properties>
  <children size="1">
    <child location="http://dist.springsource.org/release/GRECLIPSE/2.9.1/e4.3"/>
  </children>
</repository>

Note this works for this url but not for all update sites, there are different types of update sites, this one in particular is a 'composite' site pointing elsewhere.

If the problem for you is that, for whatever reason, composite sites do not work for you, then you can also try using the site it points to directly:
http://dist.springsource.org/release/GRECLIPSE/2.9.1/e4.3





[GRECLIPSE-1812] Please remove the version range in groovy-eclipse-batch Created: 19/Dec/14  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.9.1.Release
Fix Version/s: 2.9.1.Release

Type: Wish Priority: Major
Reporter: Stéphane Nicoll Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The pom deployed on central has the following dependency

<dependency>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy-eclipse-batch</artifactId>
    <version>[1.8.3-01,9.9.9)</version>
    <optional>true</optional>
</dependency> 

If the library is optional, please do not put such version range, it's completely useless.

When a SNAPSHOT repository is configured for a project relying on such pom, it will look for a snapshot of groovy-eclipse-batch. I am using https://repo.spring.io/snapshot/ which contains some snapshots of that artifact so even though I am relying on a release my build tries to resolve a SNAPSHOT version of groovy-eclipse-batch.

I would advise to use a fixed version for that artifact (since it's being optional this will have no effect). Thanks!



 Comments   
Comment by Kris De Volder [ 22/Dec/14 ]

> The pom deployed on central has the following dependency ...

You are probably talking about this pom right? http://central.maven.org/maven2/org/codehaus/groovy/groovy-eclipse-compiler/2.9.1-01/groovy-eclipse-compiler-2.9.1-01.pom
I am not sure why the dependency is marked as 'optional'. It really is required since it contains the actual compiler. Without the compiler its not possible to compile groovy code.

We could make it a fixed version, but I think that will make it impossible for people to use a specific version of groovy-eclipse-batch .

Does it work if you specify the groovy-eclipse-batch dependency explicitly in your own pom? (e.g. as in this example code:
https://github.com/groovy/groovy-eclipse/blob/master/ide-test/pom.xml#L41

Note: Groovy-eclipse-batch artifact version follows the groovy compiler version that it wraps. So specifying this dependency in your pom is
really how you tell maven which version of groovy to use for compiling your groovy code. So it is probably a good idea to
always be explicit about this.

Comment by Stéphane Nicoll [ 22/Dec/14 ]

Well I am talking of the pom of this project, yes If it shouldn't be optional, I'd argue this is a different problem.

If you put a fixed version anybody can update to whatever version they want. The version that is specified is the one that this project indicates. Using such a range (i.e. 9.9.9) is abusing the range system anyway.

To be clear, I am not complaining about the fact I can't use a different version. I could if I want but I understand I shouldn't. I am complaining that this range leads to unnecessary snapshot resolutions. If you're working with 2.9.1-01 version of the project I see no reason why it should attempt to use a different version for the groovy-eclipse-batch dependency. As you said that dependency follows the groovy compiler version that it wraps so why aren't you aligning those versions in your pom?

Thanks!

Comment by Kris De Volder [ 23/Dec/14 ]

> why aren't you aligning those versions in your pom

Because it actually wraps more than one version of the groovy compiler. (Each of the wrapped compiler versions is a separate bundle with same bundle-id but different osgi version).
Things are a bit complicated because there's two versions that matter, the version of groovy-eclipse and the version of the groovy compiler and groovy-all jar).

So every time we build 'groovy-eclipse-compiler', at the same time we produce compatible 'groovy-eclipse-batch' artefacts for several different versions of groovy.

Probably this is why it was specified as a version range.

But perhaps it would be good enough to just tie it to the latest version. Especially if you are right that users can still override it in their own pom.

> I could if I want but I understand I shouldn't.

I am not sure. I think you probably should. Actually when I use the groovy-eclipse-compiler plugin I always specify the batch dependency explicitly as I want to be in control of the groovy version used for compiling the code in our projects.

Anyway... the next time we put out groovy-eclipse-compiler and batch artefacts to maven central I will probably follow your advise and tie the latest groovy-eclipse-compiler artefact to the latest available groovy-eclipse-batch version that it is compatible with.

Comment by Stéphane Nicoll [ 02/Mar/15 ]

do you know when it's going to be fixed? I can see it goes on the codehaus snapshot repo which is really bad since it will eventually go away.

Comment by Kris De Volder [ 24/Mar/15 ]

I have just built and staged

groovy-eclipse-compiler 2.9.2-01
groovy-eclipse-batch 2.4.3-01

These are available from codehaus staging repo:
https://nexus.codehaus.org/content/groups/staging/

In a couple of days they will be released to maven central. I have replaced the version range with a optional dependency on just current last version groovy-eclipse-batch





[GRECLIPSE-1797] Weird code assist behaviour when invoking it inside brackets in a method invocation Created: 17/Oct/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.9.1.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following:

package a

import static org.junit.Assert.*

import org.junit.After;
import org.junit.Test

final class A {

	MyBean m = new MyBean()
	class MyBean {
		String doSomething(String a, Integer b) { }
	}
	@Test
	final void test() {
		assertNull(m.doSomething(|))
	}
	
}

Let "|" be the cursor position. Invoke code assist: the only useful hint is placed on the bottom on the list and may get unnoticed. Unless you hit "Ctrl+Space" repeatedly until you cycle back to "Groovy content" proposals.



 Comments   
Comment by Vasiliy Kizhaev [ 21/Oct/14 ]

Hi Mauro,
The fix has been merged: https://github.com/groovy/groovy-eclipse/pull/95

Comment by Mauro Molinari [ 21/Oct/14 ]

Great news! I look forward to testing this.





[GRECLIPSE-1794] imports get removed for AnnotationCollector classes when doing organize imports Created: 05/Oct/14  Updated: 30/Oct/14  Resolved: 14/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.9.1.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Lari Hotari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy/Grails Tool Suite 3.6.1.201408250824-RELEASE-e43


Number of attachments : 0

 Description   

GRECLIPSE-1719 fixes the compilation error, but I now have a problem that I loose imports for AnnotationCollector annotation classes when I do organize imports. Auto-importing those classes don't work either. It's easy to reproduce the problem with groovy.transform.CompileDynamic annotation.

Here's a code example:

import groovy.transform.CompileDynamic
import groovy.transform.CompileStatic

@CompileStatic
class MyExample {

    @CompileDynamic
    void dynamicMethod() {
                
    }
    
    void staticMethod() {
        
    }
}

You can reproduce the problem by doing "organize imports" on this class



 Comments   
Comment by Vasiliy Kizhaev [ 06/Oct/14 ]

I don't know why, but CompileDynamic class is not treated as an annotation but as a regular class. That is why it is being removed.
I will keep digging.
If it is really a blocker you could use "@CompileStatic(TypeCheckingMode.SKIP)" instead.
Thank you for the report.

Comment by Lari Hotari [ 06/Oct/14 ]

In Groovy the AnnotationCollector classes aren't real annotation classes. That's something how it's designed.

I'm using "@groovy.transform.CompileDynamic" as a workaround. That works and doesn't get removed when organizing imports.

Comment by Vasiliy Kizhaev [ 10/Oct/14 ]

PR for the issue is submitted https://github.com/groovy/groovy-eclipse/pull/92

Comment by Vasiliy Kizhaev [ 14/Oct/14 ]

Merged





[GRECLIPSE-1789] Eclipse compiler can't resolve traits from test classpath Created: 16/Sep/14  Updated: 02/Oct/14  Resolved: 02/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Christopher Smith Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GGTS 3.6.1


Number of attachments : 0

 Description   

In my Maven project, I have a trivial class HomePageDesktop (no body) that implements the trivial trait BoringTrait (no body), which is in src/test/java and gets correctly compiled into target/test-classes. The compile succeeds when I do a full clean and rebuild, but any incremental work, including just the parse when I open an editor, throws an exception. This problem is also present with any content in either the class or the trait. The issue disappears if I move the trait into src/main/java; it appears that the analyzer is failing to include the test classpath for resolution.

Internal Groovy Error --- exception in phase 'canonicalization' in source unit '$PROJECT_ROOT/src/test/java/com/foo/acceptance/ui/pages/desktop/HomePageDesktop.groovy' JDTClassNode.getTypeClass() cannot locate class for com.foo.acceptance.ui.pages.desktop.BoringTrait using transform loader groovy.lang.GroovyClassLoader@39630889
BUG! exception in phase 'canonicalization' in source unit '$PROJECT_ROOT/src/test/java/com/foo/acceptance/ui/pages/desktop/HomePageDesktop.groovy' JDTClassNode.getTypeClass() cannot locate class for com.foo.acceptance.ui.pages.desktop.BoringTrait using transform loader groovy.lang.GroovyClassLoader@39630889
        at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.getTypeClass(JDTClassNode.java:717)
        at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1500)
        at org.codehaus.groovy.transform.trait.Traits.findHelpers(Traits.java:112)
        at org.codehaus.groovy.transform.trait.TraitComposer.doExtendTraits(TraitComposer.java:104)
        at org.codehaus.groovy.control.CompilationUnit$11.call(CompilationUnit.java:212)
        at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1214)
        at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:645)
        at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:623)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:600)
        at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:187)
        at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.analyseCode(GroovyCompilationUnitDeclaration.java:2233)
        at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:984)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody0(CompilationUnitProblemFinder.java:207)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody1$advice(CompilationUnitProblemFinder.java:244)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:1)
        at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:330)
        at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:259)
        at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:560)
        at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:289)
        at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:275)
        at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:230)
        at org.eclipse.jdt.internal.core.JavaElement.getChildrenOfType(JavaElement.java:244)
        at org.eclipse.jdt.internal.core.CompilationUnit.getTypes(CompilationUnit.java:932)
        at org.eclipse.jdt.internal.corext.refactoring.util.JavaElementUtil.getMainType(JavaElementUtil.java:98)
        at org.eclipse.jdt.internal.corext.refactoring.RefactoringAvailabilityTester.getSingleSelectedType(RefactoringAvailabilityTester.java:157)
        at org.eclipse.jdt.ui.actions.ExtractClassAction.selectionChanged(ExtractClassAction.java:82)
        at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchSelectionChanged(SelectionDispatchAction.java:263)
        at org.eclipse.jdt.ui.actions.SelectionDispatchAction.selectionChanged(SelectionDispatchAction.java:258)
        at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:164)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
        at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
        at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:162)
        at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2188)
        at org.eclipse.jface.viewers.StructuredViewer.handleSelect(StructuredViewer.java:1211)
        at org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(StructuredViewer.java:1241)
        at org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(OpenStrategy.java:239)
        at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:233)
        at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:403)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
        at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:140)
        at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:611)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1426)


 Comments   
Comment by Denis Murashev [ 22/Sep/14 ]

The problem can be simply reproduced if output folder for trait is not the default output folder of Eclipse project.





[GRECLIPSE-1788] Wrong format when return is used Created: 12/Sep/14  Updated: 01/Oct/14  Resolved: 01/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.9.1.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Minor
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following Groovy class:

package i
class TestFormatReturn {
	MyBean soSomething() {
		new MyBean('foo',
				'bar', 'baz')
	}

	class MyBean {
		MyBean(String a, String b, String c) {}
	}
}

Now, in TestFormatReturn.doSomething() add a return statement in front of new MyBean(...) and format code. Expected result:

	MyBean soSomething() {
		return new MyBean('foo',
				'bar', 'baz')
	}

Actual result:

	MyBean soSomething() {
		return new MyBean('foo',
		'bar', 'baz')
	}

The same happens with a method call instead of a constructor call:

package i
class TestFormatReturn2 {
	MyBean soSomething() {
		bar('foo',
				'bar', 'baz')
	}

	MyBean bar(String a, String b, String c) {
		new MyBean(a, b, c)
	}

	class MyBean {
		MyBean(String a, String b, String c) {}
	}
}

If you add a return statement in front of the call to bar(String, String, String) and format code:

	MyBean soSomething() {
		return bar('foo',
		'bar', 'baz')
	}


 Comments   
Comment by Vasiliy Kizhaev [ 29/Sep/14 ]

Hi Mauro,
That's true, I can reproduce it. Labeled as 'triaged'.
Thank you!

Comment by Vasiliy Kizhaev [ 30/Sep/14 ]

PR for the bug was submitted https://github.com/groovy/groovy-eclipse/pull/89 .

Comment by Vasiliy Kizhaev [ 01/Oct/14 ]

Merged.





[GRECLIPSE-1785] Missing refactoring when using map-style constructor (part 2) Created: 08/Sep/14  Updated: 20/Oct/14  Resolved: 06/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.9.1.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the example in GRECLIPSE-1775, but this time try to rename MyBean.foo to, say, MyBean.baz: the reference in the map-style constructor call in RefactoringTest.doSomething() is not updated.



 Comments   
Comment by Mauro Molinari [ 08/Sep/14 ]

Maybe the source of the problem is the same (and the fix may be common), but if you try to navigate to the referenced field in a map-style constructor call (i.e., in the GRECLIPSE-1775 example you place the cursor over "foo:" in RefactoringTest.doSomething() and hit F3 to navigate to MyBean.foo) nothing happens. Javadoc hover and F2 don't work either.

Comment by Vasiliy Kizhaev [ 02/Oct/14 ]

PR for the issue is submitted: https://github.com/groovy/groovy-eclipse/pull/90

Comment by Vasiliy Kizhaev [ 06/Oct/14 ]

Merged

Comment by Mauro Molinari [ 20/Oct/14 ]

Fix verified in 2.9.1.xx-201410031620-e44, thank you!





[GRECLIPSE-1784] NullPointerException compiling fully qualified reference to field on inner class Created: 04/Sep/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Wesley Hartford Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested running on openJDK 6 & 7, oracle Java 8, mint linux 17.


Attachments: Zip Archive groovy-eclipse-compiler-internal-error.zip    
Issue Links:
dependent
depends upon GROOVY-7077 NullPointerException compiling fully ... Open
Testcase included: yes
Number of attachments : 1

 Description   

Compiling a class with two inner classes, one referencing a field of the other using the ClassName.this.fieldName syntax causes an error in the compiler.

I've attached a simple maven project which exhibits this issue. You should just be able to extract it, change the java.7.home property value in the pom.xml file, and run mvn compile to reproduce the error.

Sample class:

class BrokenEclipseGroovy {

  def source = new Object() {
    def field = null
  }
  def user = new Object() {
    def field = BrokenEclipseGroovy.this.source.field
  }
}

Output from mvn compile:

[INFO] Scanning for projects...
[INFO] 
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building groovy-eclipse-compiler-internal-error 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- groovy-eclipse-compiler:2.9.0-01:add-groovy-build-paths (default-add-groovy-build-paths) @ groovy-eclipse-compiler-internal-error ---
[INFO] Adding /src/main/groovy to the list of source folders
[INFO] Adding /src/test/groovy to the list of test source folders
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ groovy-eclipse-compiler-internal-error ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ groovy-eclipse-compiler-internal-error ---
[INFO] Changes detected - recompiling the module!
[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
[INFO] Found location </home/wesley/work/repository/org/codehaus/groovy/groovy-eclipse-batch/2.3.4-01/groovy-eclipse-batch-2.3.4-01.jar> for className <org.eclipse.jdt.internal.compiler.batch.Main>
[INFO] no javaAgentClass seems to be set
[INFO] Compiling in a forked process using /home/wesley/work/repository/org/codehaus/groovy/groovy-eclipse-batch/2.3.4-01/groovy-eclipse-batch-2.3.4-01.jar
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] Failure executing groovy-eclipse compiler:
Internal Groovy Error --- exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null
BUG! exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:1025)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:647)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:596)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:187)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:2150)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:827)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
	at org.codehaus.groovy.control.ResolveVisitor.checkThisAndSuperAsPropertyAccess(ResolveVisitor.java:939)
	at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:909)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:753)
	at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:876)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:753)
	at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:876)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:753)
	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitField(ClassCodeExpressionTransformer.java:65)
	at org.codehaus.groovy.control.ResolveVisitor.visitField(ResolveVisitor.java:204)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1193)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:52)
	at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1332)
	at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:167)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:565)
	at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:713)
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:1016)
	... 7 more
Status ERROR: org.eclipse.jdt.core code=4 Internal groovy compiler error. BUG! exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null
/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy: 1 Groovy:Internal groovy compiler error.
Ignoring GroovyBugError since it is likely caused by earlier issues.  Ignored problem is 'BUG! exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null'
Ignoring GroovyBugError since it is likely caused by earlier issues.  Ignored problem is 'BUG! exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null'
----------
1. ERROR in /home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy (at line 1)
	package org.codehaus.groovy.error
	^
Groovy:Internal groovy compiler error.
----------
1 problem (1 error)

[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.427 s
[INFO] Finished at: 2014-09-04T12:59:29-08:00
[INFO] Final Memory: 10M/228M
[INFO] ------------------------------------------------------------------------
[WARNING] The requested profile "development" could not be activated because it does not exist.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project groovy-eclipse-compiler-internal-error: Compilation failure
[ERROR] Failure executing groovy-eclipse compiler:
[ERROR] Internal Groovy Error --- exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null
[ERROR] BUG! exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null
[ERROR] at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:1025)
[ERROR] at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:647)
[ERROR] at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:596)
[ERROR] at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:187)
[ERROR] at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:2150)
[ERROR] at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:827)
[ERROR] at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
[ERROR] at java.lang.Thread.run(Thread.java:745)
[ERROR] Caused by: java.lang.NullPointerException
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.checkThisAndSuperAsPropertyAccess(ResolveVisitor.java:939)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:909)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:753)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:876)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:753)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:876)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:753)
[ERROR] at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitField(ClassCodeExpressionTransformer.java:65)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.visitField(ResolveVisitor.java:204)
[ERROR] at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1193)
[ERROR] at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:52)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1332)
[ERROR] at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:167)
[ERROR] at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:565)
[ERROR] at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:713)
[ERROR] at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:1016)
[ERROR] ... 7 more
[ERROR] Status ERROR: org.eclipse.jdt.core code=4 Internal groovy compiler error. BUG! exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null
[ERROR] /home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy: 1 Groovy:Internal groovy compiler error.
[ERROR] Ignoring GroovyBugError since it is likely caused by earlier issues.  Ignored problem is 'BUG! exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null'
[ERROR] Ignoring GroovyBugError since it is likely caused by earlier issues.  Ignored problem is 'BUG! exception in phase 'semantic analysis' in source unit '/home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy' null'
[ERROR] ----------
[ERROR] 1. ERROR in /home/wesley/work/projects/explode/groovy-eclipse-compiler-internal-error/src/main/groovy/org/codehaus/groovy/error/BrokenEclipseGroovy.groovy (at line 1)
[ERROR] package org.codehaus.groovy.error
[ERROR] ^
[ERROR] Groovy:Internal groovy compiler error.
[ERROR] ----------
[ERROR] 1 problem (1 error)
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException


 Comments   
Comment by Denis Murashev [ 18/Sep/14 ]

Actually there is a problem inside Groovy. Groovy compiler fails to compile code described above.





[GRECLIPSE-1780] Groovy 2.0 broken Created: 21/Aug/14  Updated: 29/Aug/14  Resolved: 29/Aug/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Andy Clement Assignee: Denis Murashev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I mentioned this a while back through less formal channels but it still hasn't been fixed so I guess I need to raise an issue. From the mailing list:

===
I'm running Eclipse Luna, with the Groovy Eclipse plugin 2.9.1-xx.20140811, with the 2.0 compiler.

For groovy files in a several of my projects, when I open and then click anywhere in the editor window, I get this error repeated over and over (and I have to keep acknowledging the popup dialog):

eclipse.buildId=4.4.0.I20140606-1215
java.fullversion=JRE 1.7.0 IBM J9 2.6 Linux amd64-64 Compressed References 20140409_195732 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR7_20140409_1418_B195732
JIT - r11.b06_20140409_61252
GC - R26_Java726_SR7_20140409_1418_B195732_CMPRSS
J9CL - 20140409_195732
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product

org.eclipse.core.jobs
Error
Tue Aug 12 09:56:09 CDT 2014
An internal error occurred during: "Requesting Java AST from selection".

java.lang.NoSuchMethodError: org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.<init>(Lorg/codehaus/groovy/control/SourceUnit;Lorg/codehaus/groovy/ast/ClassNode;)V
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor$1Helper.<init>(TypeInferencingVisitorWithRequestor.java:1680)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.inferGenericMethodType(TypeInferencingVisitorWithRequestor.java:1687)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1666)
at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:67)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:122)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:236)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:88)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:206)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1400)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:103)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:114)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstructorOrMethod(TypeInferencingVisitorWithRequestor.java:834)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:563)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:396)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:344)
at org.codehaus.groovy.eclipse.search.GroovyOccurrencesFinder.internalFindOccurences(GroovyOccurrencesFinder.java:179)
at org.codehaus.groovy.eclipse.search.GroovyOccurrencesFinder.getOccurrences(GroovyOccurrencesFinder.java:103)
at org.codehaus.groovy.eclipse.editor.GroovyEditor.updateOccurrenceAnnotations(GroovyEditor.java:1260)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$6.selectionChanged(JavaEditor.java:3380)
at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:178)
at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

After I close all the popups, if I continue trying to edit, the popups start again.

This was happening with the milestone build as well, and I switch to the dev build on the off chance it had been fixed.

Let me know what I can provide to help you track this down.

Thanks!!
===

It is easy to see the problem in the IDE, just close all the compilers but org.codehaus.groovy20 and the compile errors are shown in the org.eclipse.jdt.groovy.core plugin. We need to fix the compile errors at least, we don't necessarily have to get this functionality to work if it is only intended for use on later compiler versions.






[GRECLIPSE-1778] Applying "each" proposal in empty ".groovy" file causes an NPE Created: 11/Aug/14  Updated: 11/Aug/14  Resolved: 11/Aug/14

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Minor
Reporter: Vasiliy Kizhaev Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Steps to reproduce:
1. Open an empty groovy file in editor
2. Put cursor in the editor
3. Call content assist (Ctrl + Space)
4. Choose "each" method proposal
5. Watch the NPE in Error Log

This can be reproduced at any position of any groovy file and not only with "each" proposal, but with every method proposal applied to nothing.



 Comments   
Comment by Vasiliy Kizhaev [ 11/Aug/14 ]

PR for the issue submitted: https://github.com/groovy/groovy-eclipse/pull/80

Comment by Vasiliy Kizhaev [ 11/Aug/14 ]

Merged.





[GRECLIPSE-1777] Add "add cast to..." quick fix Created: 07/Aug/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Improvement Priority: Major
Reporter: Mauro Molinari Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following:

package d

import groovy.transform.CompileStatic;

@CompileStatic
class D {
	
	Number foo() {
		new Integer(1)
	}
	
	Integer bar() {
		Integer result = foo()
		result
	}
}

Put the cursor on the foo() call in bar() implementation (either at the beginning, or in the middle, or in the end). There's an error there, because foo() returns Number, while result is Integer. It would be very useful if there were the quick fix "Add cast to <type>" (where <type> is Integer in this case) just like there's in JDT editor for Java files.

When working with static type checking and/or static compilation, this is extremely useful especially when working with legacy non-generified libraries.

Other similar use case may imply simply return foo() (without the intermediate assignment to result) or even just foo() (since "return" is optional in Groovy).






[GRECLIPSE-1776] Adding a new method to a trait gives compilation error on existing implementors Created: 06/Aug/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Minor
Reporter: Ken Krebs Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

2.3.3 Groovy compiler


Number of attachments : 0

 Description   

If you have a trait and some implementors, when you add a new method to the trait, the implementors all get a compile error: "Can't have an abstract method in a non-abstract class ...".

This can be rectified by cleaning the project but is obviously wrong and a small nuisance.



 Comments   
Comment by Carl Pritchett [ 15/Aug/14 ]

I get the abstract error in the editor (not in the problems/errors tab) when implementing a trait, but it never goes away (clean doesn't help). Luna with Groovy-Eclipse Feature 2.9.0.xx-201407142235-e44-RELEASE.

Compiles and runs so it's an editor annoyance only.





[GRECLIPSE-1775] Missing refactoring when using map-style constructor and setting properties from another bean or static fields Created: 05/Aug/14  Updated: 01/Sep/14  Resolved: 14/Aug/14

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Considering the following Groovy classes:

package c

class MyBean {
	String foo
	
	void setBar(String bar) {
		foo = bar.toUpperCase()
	}
}
package c

import groovy.transform.CompileStatic;

@CompileStatic
class RefactoringTest {
   void doSomething() {
	   def b1 = new MyBean()
	   MyBean b2 = new MyBean(foo: b1.foo)
   }
}

Now try to rename b1 to b12 by refactoring: the b1 reference on the second line (where b2 is created) is not updated accordingly.

Note: if b1 were a simple String and b2.foo were initialised to b1 directly (instead of to a property of b1), the refactoring works ok.



 Comments   
Comment by Mauro Molinari [ 06/Aug/14 ]

Another failing case:

def b3 = new MyBean(foo: AnotherClass.doSomething())

then rename AnotherClass. That is, in this case the refactoring involves a class name, rather than a variable name.

Comment by Vasiliy Kizhaev [ 14/Aug/14 ]

Issue has been fixed and merged.

Comment by Mauro Molinari [ 01/Sep/14 ]

Fix verified in 2.9.1.xx-201408202052-e44 for both the original case and the one in the first comment. Thank you!





[GRECLIPSE-1774] Create groovy-eclipse-batch 2.3.6 and 2.2.1 releases Created: 05/Aug/14  Updated: 25/Mar/15  Resolved: 25/Mar/15

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.9.0.Release
Fix Version/s: None

Type: Task Priority: Major
Reporter: Kris De Volder Assignee: Kris De Volder
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As per request on greclipse mailing list we should put out a 'release' of the latest greclipse compiler in the 2.2.x line.

There is also a new groovy compiler in the 2.3.x line: 2.3.6 which should be 'mavenized'.



 Comments   
Comment by Kris De Volder [ 05/Aug/14 ]

I just created a groovy-eclipse-batch 2.2.1-01 release. This is staged to codehaus staging repo.
I.e : https://nexus.codehaus.org/content/groups/staging/

I'm holding of on publishing this to maven central for a few days to give a someone a chance for testing.

Chris Hamilton asked for this release on greclipse mailing list. So Chris, hopefully you can try it out quickly and let me know if it works for you?

Comment by Kris De Volder [ 05/Aug/14 ]

groovy-eclipse-batch 2.3.6-01 release also staged now. Should be compatible with groovy-eclipse-compiler 2.9.0-01.

Also holding of on publishing this to maven central for a couple of days to give someone a chance to test it.

Comment by Bjorn Beskow [ 17/Sep/14 ]

I have been using groovy-eclipse-batch 2.3.6-01 in several projects for the last month. It works just as expected, so I believe it can be released to maven central.

Comment by Kris De Volder [ 25/Mar/15 ]

This issue seems to have dropped between the cracks. But there is already a newer compiler out on central and soon there will be a 2.4.3 as well so I'll just close this one now.





[GRECLIPSE-1773] Incremental builds not recompiling eveything they need to Created: 05/Aug/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Vasiliy Kizhaev Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GRECLIPSE-1450 Incremental compilation fails on "cir... Open
Number of attachments : 0

 Description   

Noticed classes with mutual references can confuse the Groovy builder - when introducing an error that breaks the other, fixing the error is not enough to get rid of the compilation errors. A manual rebuild of the files is required.
To reproduce:
1) Have a groovy project with a three classes in the same package (different compilation units:

package test
abstract class Class1 {
    abstract void m1()

    void m2() {
    }

    static Class1 create(String type) {
        switch (type) {
            case 'Class2' :
                return new Class2()
                break
            case 'Class3' :
                return new Class3()
            default : 
                assert false : "Unexpected type ${type}"
        }
}
}
package test
class Class2 extends Class1 {
    @Override
    public void m1() {
    }
}
package test
class Class3 extends Class1 {
    @Override
    public void m1() {
    }
}

2) Remove the method name from Class1:
abstract void ()
3) Save - note the errors in all three classes
4) Fix it by setting the name to m1
5) Note how that all three classes have errors now.
6) Project > Clean... -> Rebuild -> Problem solved

Copied from: https://issuetracker.springsource.com/browse/STS-3879



 Comments   
Comment by Andy Clement [ 05/Aug/14 ]

After a bit of thinking I suspect this may be related to lack of recoverability in the groovy parser - that may be disturbing the ability to properly record dependencies. But needs some digging to confirm.





[GRECLIPSE-1765] Unexpected Internal groovy compiler error Created: 24/Jul/14  Updated: 04/Aug/14  Resolved: 29/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Denis Murashev Assignee: Denis Murashev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy 2.3.4


Attachments: Text File error_log.txt    
Issue Links:
Related
relates to GRECLIPSE-1751 Type inference on "with" closure not ... In Progress
Number of attachments : 1

 Description   

I tried to reproduce GRECLIPSE-1751 with Groovy 2.3 and got unexpected Internal groovy compiler error. Error log is attached.



 Comments   
Comment by Mauro Molinari [ 04/Aug/14 ]

Try to use a newer Groovy version (2.3.4 or newer). It might solve this error, since they put in some fixes regarding static compilation. I did not get this specific error when I wrote that use case....

Oh, I see now you're already using 2.3.4... that's strange... What about an even newer one (2.3.6 is out right now)? Does the groovyc fails in the same way? If so, you may open a bug against Groovy itself. Otherwise please note that some differences between plain Groovy and Greclipse compilation with regards to the use of with have been seen by myself in GRECLIPSE-1760, but it seems to be a different issues and I don't know whether it might be related to this in some way...

Sorry, just saw this is already fixed... I must be blind...





[GRECLIPSE-1759] java.lang.NoClassDefFoundError: [Lorg/eclipse/core/runtime/ILibrary; Created: 11/Jul/14  Updated: 14/Jul/14  Resolved: 14/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.8.0.Release, 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Kris De Volder
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK7, Eclipse 4.3.2


Number of attachments : 0

 Description   

Reproduced as follows:

  • Get fresh Eclipse 4.3.2 Standard
  • Installed Greclipse snapshot
  • Installed this update site http://mirror.anl.gov/repastsimphony
  • Right click in the Package Explorer and choose New -> ReLogo Project, and click Finish.

A project is created, each time the project is built it causes this error.

java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin cannot be found by org.eclipse.equinox.registry_3.5.301.v20130717-1549
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2570)
	at java.lang.Class.privateGetPublicMethods(Class.java:2690)
	at java.lang.Class.getMethods(Class.java:1467)
	at org.codehaus.groovy.reflection.stdclasses.CachedSAMClass.getSAMMethod(CachedSAMClass.java:160)
	at org.codehaus.groovy.reflection.ClassInfo.isSAM(ClassInfo.java:323)
	at org.codehaus.groovy.reflection.ClassInfo.createCachedClass(ClassInfo.java:313)
	at org.codehaus.groovy.reflection.ClassInfo.access$400(ClassInfo.java:37)
	at org.codehaus.groovy.reflection.ClassInfo$LazyCachedClassRef.initValue(ClassInfo.java:484)
	at org.codehaus.groovy.reflection.ClassInfo$LazyCachedClassRef.initValue(ClassInfo.java:475)
	at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
	at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
	at org.codehaus.groovy.reflection.ClassInfo.getCachedClass(ClassInfo.java:94)
	at org.codehaus.groovy.reflection.ReflectionCache.getCachedClass(ReflectionCache.java:107)
	at org.codehaus.groovy.reflection.ParameterTypes.getParametersTypes0(ParameterTypes.java:78)
	at org.codehaus.groovy.reflection.ParameterTypes.getParameterTypes(ParameterTypes.java:64)
	at org.codehaus.groovy.runtime.metaclass.MetaMethodIndex.isMatchingMethod(MetaMethodIndex.java:450)
	at org.codehaus.groovy.runtime.metaclass.MetaMethodIndex.addMethodToList(MetaMethodIndex.java:375)
	at groovy.lang.MetaClassImpl.addMetaMethodToIndex(MetaClassImpl.java:2742)
	at groovy.lang.MetaClassImpl.populateMethods(MetaClassImpl.java:317)
	at groovy.lang.MetaClassImpl.fillMethodIndex(MetaClassImpl.java:292)
	at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:3045)
	at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:210)
	at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:241)
	at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:251)
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:259)
	at org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.java:855)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.createPojoSite(CallSiteArray.java:122)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:163)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
	at repast.simphony.relogo.ide.handlers.ContextAndDisplayUtilsGroovy.checkToModifyContextFile(ContextAndDisplayUtilsGroovy.groovy:38)
	at repast.simphony.relogo.ide.handlers.ReLogoBuilder$FullBuildInstrumentationInformationVisitor.checkContextAndDisplayFiles(ReLogoBuilder.java:748)
	at repast.simphony.relogo.ide.handlers.ReLogoBuilder$FullBuildInstrumentationInformationVisitor.visit(ReLogoBuilder.java:627)
	at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:126)
	at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:85)
	at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:82)
	at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86)
	at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86)
	at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86)
	at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86)
	at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:127)
	at org.eclipse.core.internal.resources.Resource.accept(Resource.java:95)
	at org.eclipse.core.internal.resources.Resource.accept(Resource.java:52)
	at org.eclipse.core.internal.resources.Resource.accept(Resource.java:124)
	at org.eclipse.core.internal.resources.Resource.accept(Resource.java:108)
	at repast.simphony.relogo.ide.handlers.ReLogoBuilder.fullBuild(ReLogoBuilder.java:185)
	at repast.simphony.relogo.ide.handlers.ReLogoBuilder.build(ReLogoBuilder.java:153)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)


 Comments   
Comment by Kris De Volder [ 11/Jul/14 ]

I am also able to reproduce the same error from a simple JUnit test that tries to use java reflection to do this:

	public void testIt() throws Exception {
		Class<?> klass = Class.forName("org.eclipse.core.runtime.IPluginDescriptor");
		System.out.println(klass);
		Method[] methods = klass.getMethods();
		for (Method method : methods) {
			System.out.println(method);
		}
	}

This test is placed in a new eclipse plugin that only depends on the 'org.eclipse.core.runtime', bundle then it is run as a JUnit plugin test.
I run this test in the eclipse setup as described above (i.e. with repast and greclipse snapshot installed).

Comment by Kris De Volder [ 11/Jul/14 ]

I tried running the above test in fresh copy of Eclipse 4.3.2 and I'm getting the same result.
So it appears that the problem is present in Eclipse even without installing greclipse or repaste.

Also looking at the original stacktrace, it appears it contains no greclipse code. As far as I can tell it is caused by the repaste builder using groovy and then groovy classloading and using reflection on stuff it gets from the runtime classpath of the plugin hosting the repaste builder.

So it looks to me there isn't much that we (i.e. greclipse) can do about this.

Comment by Kris De Volder [ 11/Jul/14 ]

Interestingly, running the same test in fresh Eclipse 4.4 also fails in a very similar way, but with a different ClassNF exception.
java.lang.NoClassDefFoundError: [Lorg/eclipse/core/runtime/IPluginPrerequisite;

Comment by Kris De Volder [ 11/Jul/14 ]

What I am unsure of is whether this problem is a problem with Eclipse (packaging of the 'org.eclipse.core.runtime' bundle) or not.
It seems a lot of Eclipse code is running on top of this bundle without any issue.

Perhaps the problem is with how the client bundle imports its dependency.

Comment by Kris De Volder [ 11/Jul/14 ]

Interesting... running a test like this from my (same) test bundle actually works

	public void testMore() throws Exception {
		IPluginDescriptor pds = new MockPluginDescriptor();
		ILibrary alib = pds.getRuntimeLibraries()[0];
	}

So while there seem to be problems using reflection on the `IPluginDescriptor` class, implementing/using it is not a problem.

Comment by Kris De Volder [ 14/Jul/14 ]

Closing. Doesn't appear to be a problem with Greclipse.

I have raised a bug with eclipse, maybe this is something that can/needs to be fixed in how eclipse packages these classes.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=439554





[GRECLIPSE-1756] No download version for Eclipse Luna Created: 07/Jul/14  Updated: 01/Sep/14  Resolved: 17/Jul/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Nick Vaidyanathan Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

http://groovy.codehaus.org/Eclipse+Plugin does not have a download link for the newest Eclipse 4.4 (Luna). When I try to install the one from Kepler within Eclipse, it fails. Can we get a new version generated, soon?



 Comments   
Comment by Andy Clement [ 08/Jul/14 ]

The link isn't there (we are in the midst of addressing that), but greclipse has happily been on 4.4 for some time:

http://dist.springsource.org/snapshot/GRECLIPSE/e4.4

Comment by Vasiliy Kizhaev [ 17/Jul/14 ]

The link is there now. Closed.

Comment by Mauro Molinari [ 01/Sep/14 ]

Hi Visiliy, maybe this is the best place to note that the page at http://groovy.codehaus.org/Eclipse+Plugin is still outdated with regards to the released version update site.

Comment by Mauro Molinari [ 01/Sep/14 ]

Also, version 2.9.0 here in JIRA is still denoted as unreleased.





[GRECLIPSE-1755] Wrong method call detected Created: 07/Jul/14  Updated: 01/Sep/14  Resolved: 10/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Parser
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Suppose you depend on org.hibernate:hibernate-core:3.5.6-Final and that you have:

class F {
	static main(args) {
		SessionFactory sf = new SessionFactoryImpl(null, null, null, null, null)
		SQLQuery query = sf.currentSession.createSQLQuery('SELECT BLA BLA')
	}
}

This snippet is nonsense, but it serves the purpose. Here, the call to createSQLQuery(String) is confused by Greclipse with createSQLQuery(String, String, Class), which is deprecated, so the editor shows the deprecation decoration on my call.

Using Greclipse 2.9.0.xx-201405030018-e43j8.



 Comments   
Comment by Vasiliy Kizhaev [ 10/Jul/14 ]

PR for the issue is submitted https://github.com/groovy/groovy-eclipse/pull/62

Comment by Mauro Molinari [ 01/Sep/14 ]

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!





[GRECLIPSE-1753] Comments in if/else statement without blocks cause wrong formatting Created: 04/Jul/14  Updated: 01/Sep/14  Resolved: 07/Aug/14

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using 2.9.0.xx-201405030018-e43j8

Consider the following Groovy class:

package g

class G2 {
	void foo() {
 		if(true)
			// print true
			println('true')
		 else
			// print false
			println('false')
	}
}

Format it using Ctrl+Shift+F. This is the result:

package g

class G2 {
	void foo() {
 		if(true)
		// print true
		println('true')
		else
		// print false
		println('false')
	}
}

That is: line comments cause the two println() statements to be wrongly indented.



 Comments   
Comment by Vasiliy Kizhaev [ 21/Jul/14 ]

The bug is fixed and will be merged soon. Thank you, Mauro!

Comment by Vasiliy Kizhaev [ 23/Jul/14 ]

PR for the issue is submitted: https://github.com/groovy/groovy-eclipse/pull/71

Comment by Mauro Molinari [ 01/Sep/14 ]

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!





[GRECLIPSE-1752] Static members not proposed when @CompileStatic is used Created: 03/Jul/14  Updated: 01/Sep/14  Resolved: 10/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using Greclipse 2.9.0.xx-201405030018-e43j8.

Consider the following Java class:

package g;
public class Utils {
  public static String CONSTANT = "bar";
  public static void util() {
  }
}

and the following Groovy class:

package g
import groovy.transform.CompileStatic;
@CompileStatic
class G {
  void foo() {
	  Utils.|
  }
}

Invoke code assist at "|" and search for the static members of Utils (util() method and/or CONSTANT constant): Greclipse won't propose anything.
If you remove @CompileStatic from G, those members are correctly proposed instead.



 Comments   
Comment by Denis Murashev [ 03/Jul/14 ]

@TypeChecked also breaks proposals for static members

Comment by Mauro Molinari [ 01/Sep/14 ]

Fix verified in 2.9.1.xx-201408202052-e44 for both @CompileStatic and @TypeChecked. Thank you!

However please note I opened GRECLIPSE-1782 as a usability improvement.





[GRECLIPSE-1749] Version 2.9.0.xx-201405271533-e44 re-introduces Eclipse compiler bug with annotation and generics Created: 26/Jun/14  Updated: 27/Jun/14  Resolved: 27/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.9.0.Release
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Steven Dick Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 sp1 x64, Eclipse x64 4.4


Testcase included: yes
Number of attachments : 0

 Description   

With version 2.9.0.xx-201405271533-e44 installed, the following Eclipse bug is re-introduced when compiling: https://bugs.eclipse.org/bugs/show_bug.cgi?id=434570

The original bug report has a very short reproduction from Spring's Sam Brannen.

I confirmed the reproduction code fails when the Groovy plug-in is installed and works when the plug-in is removed.



 Comments   
Comment by Andy Clement [ 26/Jun/14 ]

JDT core was upgraded in greclipse on 11 Jun - can you try a more recent snapshot than 27 May?

Comment by Steven Dick [ 27/Jun/14 ]

I was using the STS Groovy/Grails update site to install: http://dist.springsource.com/milestone/TOOLS/update/e4.4/ - this is currently version 3.6,0,m1 of STS

I've now tested using the http://dist.springsource.org/milestone/GRECLIPSE/e4.4/ update site and installed version 2.9.0.xx-201406270115-e44 and this fixes the compiler bug.

Comment by Andy Clement [ 27/Jun/14 ]

@Steven - Thanks for trying out a new version, I'm glad it works for you. And thanks for describing what versions you were picking up from where, that may help another user who hits it. STS 3.6.0 final isn't too far off with all the latest stuff folded in.





[GRECLIPSE-1748] Type inference not recognizing closure parameter value Created: 20/Jun/14  Updated: 01/Sep/14  Resolved: 12/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged, type-inference
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following:

class A {
  @Bindable
  String foo
  
  static void main(String[] args) {
	  A a = new A()
	  a.foo = 'old'
	  a.addPropertyChangeListener('foo') {
		  println 'foo changed: ' + it.oldValue + ' -> ' + it.newValue
	  }
	  a.foo = 'new'
  }
}

Greclipse does not recognize the type of it, which is PropertyChangeEvent, and underlines oldValue and newValue.
This is unexpected, because if you add the @TypeChecked annotation to A, those properties are correctly recognized: this makes me think the information about its type should be there.



 Comments   
Comment by Mauro Molinari [ 01/Sep/14 ]

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!





[GRECLIPSE-1746] An anonymous class using a this reference should not break RSPEC-1604 Created: 19/Jun/14  Updated: 23/Jun/14  Resolved: 23/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: gontard Assignee: Unassigned
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This code is noncompliant with the rule RSPEC-1604 implemented in SONARJAVA-455 "Anonymous inner classes containing only one method should become lambdas".

But this anonymous class implementation use a this reference. So is not convertible to a lambda:

observable.addObserver(new Observer() {
    public void change() {
        observable.removeObserver(this);
    }
});


 Comments   
Comment by gontard [ 23/Jun/14 ]

this issue was opened on the wrong project.





[GRECLIPSE-1745] Greclipse compiler Breaking JDT compilation on Eclipse 4.4? Created: 11/Jun/14  Updated: 11/Jun/14  Resolved: 11/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Critical
Reporter: Kris De Volder Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Here is how I observe(d) the errors.

*) Get STS 3.6.0.M1, run it with JDK 7.
*) create a new workspace
*) Update STS 'core' from nightly: http://dist.springframework.org/snapshot/IDE/nightly
*) Disable 'auto detection': Window >> Preferences >> Spring >> Bean Support" bottom of the page.
*) clone spring boot repo: https://github.com/spring-projects/spring-boot
*) import all projects from the root using 'import existing maven project'.
(ignore errors about missing maven plugins the wizard complains about).

After maven did all its stuff... you should have a 'almost clean' workspace. Just some errors in 'spring-boot-maven-plugin' and 'spring-boot-gradle-plugin'.

*) close the 2 projects with errors in them.

You should know have a 'clean' workspace. May be good to do some 'update maven project' and/or workspace clean builds to make sure there's really no 'hidden' build errors.

*) install greclipse:
site: http://dist.springsource.org/snapshot/GRECLIPSE/e4.4
install greclipse feature and the 2.3 compiler (actually should be included in the feature).

*) restart and rebuild workspace
=> some errors involving annotations (projects: spring-boot-autoconfigure, spring-boot-actuator)

One that looks important (root cause?) is:
Type mismatch: cannot convert from Class<OnClassCondition> to Class<? extends Condition>[]
In /spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/condition/ConditionalOnClass.java

*) uninstall greclipse feature and compilers, restart, rebuild

=> no more errors.



 Comments   
Comment by Andy Clement [ 11/Jun/14 ]

Appears fixed by update of jdt core to c0f9341





[GRECLIPSE-1743] JDT patch for e44 needs an update Created: 09/Jun/14  Updated: 12/Jun/14  Resolved: 12/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It looks like the 'apt' bundle in e44 RC2 is making use of some non-public API that got added after we took our snapshot for the JDT patch.

See this bug for some details: https://jira.codehaus.org/browse/GRECLIPSE-1733?focusedCommentId=347661&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-347661

The missing field appears to be this one defined on line 51 here:
http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/lookup/CompilationUnitScope.java
The field is called 'suppressImports'.



 Comments   
Comment by Andy Clement [ 12/Jun/14 ]

Upgraded to JDT Core c0f9341 (the latest version as of yesterday)





[GRECLIPSE-1742] "IllegalArgumentException: Not a source member" performing a search Created: 06/Jun/14  Updated: 06/Jun/14  Resolved: 06/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Search
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
 java.lang.IllegalArgumentException: Not a source member runServer(java.util.Map) [in GrailsProjectRunner [in GrailsProjectRunner.class [in org.codehaus.groovy.grails.project.container [in /home/kdvolder/.m2/repository/org/grails/grails-project-api/2.4.0/grails-project-api-2.4.0.jar]]]]

	at org.eclipse.jdt.internal.core.Member.getType(Member.java:351)
	at org.codehaus.groovy.eclipse.core.model.GroovyProjectFacade.findAnonymousInnerClass(GroovyProjectFacade.java:169)
	at org.codehaus.groovy.eclipse.core.model.GroovyProjectFacade.groovyClassToJavaType(GroovyProjectFacade.java:125)
	at org.grails.ide.eclipse.editor.groovy.elements.GrailsProject.getUnit(GrailsProject.java:367)
	at org.grails.ide.eclipse.editor.groovy.elements.GrailsProject.getGrailsElement(GrailsProject.java:382)
	at org.grails.ide.eclipse.editor.groovy.types.GrailsTypeLookup.lookupTypeAndDeclaration(GrailsTypeLookup.java:79)
	at org.eclipse.jdt.groovy.search.AbstractSimplifiedTypeLookup.lookupType(AbstractSimplifiedTypeLookup.java:134)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.lookupExpressionType(TypeInferencingVisitorWithRequestor.java:1908)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleSimpleExpression(TypeInferencingVisitorWithRequestor.java:1878)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstantExpression(TypeInferencingVisitorWithRequestor.java:1400)
	at org.codehaus.groovy.ast.expr.ConstantExpression.visit(ConstantExpression.java:79)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1563)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:64)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:71)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:236)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:37)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:206)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1331)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:103)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:114)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstructorOrMethod(TypeInferencingVisitorWithRequestor.java:818)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:549)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:382)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:555)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:382)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:330)
	at org.codehaus.jdt.groovy.integration.internal.GroovyLanguageSupport.maybePerformDelegatedSearch(GroovyLanguageSupport.java:199)
	at org.codehaus.jdt.groovy.integration.LanguageSupportFactory.maybePerformDelegatedSearch(LanguageSupportFactory.java:107)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1106)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1234)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1366)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:122)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:232)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:516)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:592)
	at org.codehaus.groovy.eclipse.core.search.SyntheticAccessorSearchRequestor.findSyntheticMatches(SyntheticAccessorSearchRequestor.java:372)
	at org.codehaus.groovy.eclipse.search.SyntheticAccessorQueryParticipant.search(SyntheticAccessorQueryParticipant.java:124)
	at org.eclipse.jdt.internal.ui.search.JavaSearchQuery$2.run(JavaSearchQuery.java:164)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:170)
	at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:91)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

To reproduce follow instructions from:
https://jira.codehaus.org/browse/GRECLIPSE-1741

The error appears in the error log.



 Comments   
Comment by Kris De Volder [ 06/Jun/14 ]

Fix committed





[GRECLIPSE-1733] Create groovy-eclipse-batch maven artifact for Groovy 2.3.4 Created: 13/May/14  Updated: 07/Nov/14  Resolved: 16/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Task Priority: Major
Reporter: Steve Ash Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Create a groovy-eclipse-batch maven artifact for groovy eclipse compiler for groovy 2.3.0 to include the java 8 support



 Comments   
Comment by Andy Clement [ 20/May/14 ]

I assume we'll do 2.3.1 under this bug, not 2.3.0

Comment by Kris De Volder [ 21/May/14 ]

I've built and deployed new snapshot version of groovy-eclipse-compiler 2.9.0 and groovy-eclipse-batch 2.3.1 to codehaus snapshot repository.

Steve if you got a chance to try it please do.

Comment by Paul Sideleau [ 28/May/14 ]

I've compiled our code with Java 8 and latest snapshot versions. Our code compiled and all spock tests executed without any issues.

However, groovy 2.3.2 was just released and has a critical bug fix. https://jira.codehaus.org/browse/GROOVY-6808. Could you please update to use 2.3.2?

Thank you.

Comment by Steve Ash [ 05/Jun/14 ]

Any ETA on this?

Comment by Kris De Volder [ 05/Jun/14 ]

Before we can do the maven bit... greclipse compiler itself needs to be update to 2.3.2.

EDIT: actually... it looks lie Andy did this silently already. I checked the bundle manifest in groovy23 bundle and it says '2.3.2'.

Comment by Kris De Volder [ 05/Jun/14 ]

Let me try and get another snapshot for greclipse compiler and batch out to codehaus snapshot repo now. I'll post a update when its ready to try out.

Comment by Kris De Volder [ 05/Jun/14 ]

New snapshots for groovy-eclipse-compiler-2.9.0 and groovy-eclipse-batch-2.3.2 should now be available on codehaus snapshot repo.
Please try them out.

Comment by Kris De Volder [ 05/Jun/14 ]

Groovy 2.3.3 seems imminent. Changed the title of issue to 2.3.3.
Hopefully 2.3.3 will be the last of the 2.3.x line.
We should probably do 2.3.3 compiler support and maven repackaging to coincide with 2.9.0 release.

Comment by Paul Sideleau [ 05/Jun/14 ]

I agree.

However, I am now get the following error when attempting to compile using the groovy-eclipse-batch 2.3.2-01-SNAPSHOT:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project databaseUtil: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-compiler-plugin:3.1:compile: java.lang.NoSuchFieldError: suppressImportErrors
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.apache.maven.plugins:maven-compiler-plugin:3.1

The error does not occur when I switch back to 2.3.1

Thank you

Comment by Kris De Volder [ 06/Jun/14 ]

I didn't get that error, but the tests I have are very simple (in terms of the groovy code it compiles).

However, what this looks like is probably an incompatibility between API in the 'groovy-eclipse-compiler' and 'groovy-compiler-batch' artifacts.
Can you make sure to use 2.9.0 snapshot of the groovy-eclipse-compiler with the new groovy-compiler-batch?

If you already doing that, or you still get the error after doing that, then I will probably need a test case to figure out what the problem might be exactly.

It might also help to get a full stacktrace of the error so maybe running maven with -X option may show something that helps determine the exact place the 'incompatible API' call originates from.

Comment by Kris De Volder [ 06/Jun/14 ]

For easy reference, here's an excerpt from pom.xml from one of the regression test that gets executed and seems to work with the currently deployed snapshots:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
				<version>3.1</version>
        <configuration>
          <compilerId>groovy-eclipse-compiler</compilerId>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.9.0-01-SNAPSHOT</version>
          </dependency>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-batch</artifactId>
            <version>2.3.2-01-SNAPSHOT</version>
          </dependency>
        </dependencies>
      </plugin>

To ensure we are using the same versions. The exact version of the artifacts the test ends up using (downloaded from codehaus snapshot repo) are:
groovy-eclipse-compiler 2.9.0-01-20140605.173410-11
groovy-eclipse-batch 2.3.2-01-20140605.173311-1

Comment by Paul Sideleau [ 07/Jun/14 ]

I cleared out my local m2 repository but I'm still getting the same error. I confirmed that my pom file settings and snapshot versions match yours.

My java version is "1.8.0_05"

I tried with maven 3.2.1 and 3.1.1 and got the same error

My project is a multi-module project.

Here is my debug output:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project databaseUtil: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-compiler-plugin:3.1:compile: java.lang.NoSuchFieldError: suppressImportErrors
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.apache.maven.plugins:maven-compiler-plugin:3.1
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/Users/paulsideleau/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.jar
[ERROR] urls[1] = file:/Users/paulsideleau/.m2/repository/org/codehaus/groovy/groovy-eclipse-compiler/2.9.0-01-SNAPSHOT/groovy-eclipse-compiler-2.9.0-01-SNAPSHOT.jar
[ERROR] urls[2] = file:/Users/paulsideleau/.m2/repository/org/codehaus/groovy/groovy-eclipse-batch/2.3.2-01-SNAPSHOT/groovy-eclipse-batch-2.3.2-01-SNAPSHOT.jar
[ERROR] urls[3] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar
[ERROR] urls[4] = file:/Users/paulsideleau/.m2/repository/org/apache/maven/shared/maven-shared-utils/0.1/maven-shared-utils-0.1.jar
[ERROR] urls[5] = file:/Users/paulsideleau/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
[ERROR] urls[6] = file:/Users/paulsideleau/.m2/repository/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.jar
[ERROR] urls[7] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[8] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-compiler-api/2.2/plexus-compiler-api-2.2.jar
[ERROR] urls[9] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-compiler-manager/2.2/plexus-compiler-manager-2.2.jar
[ERROR] urls[10] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-compiler-javac/2.2/plexus-compiler-javac-2.2.jar
[ERROR] urls[11] = file:/Users/paulsideleau/.m2/repository/org/apache/xbean/xbean-reflect/3.4/xbean-reflect-3.4.jar
[ERROR] urls[12] = file:/Users/paulsideleau/.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar
[ERROR] urls[13] = file:/Users/paulsideleau/.m2/repository/commons-logging/commons-logging-api/1.1/commons-logging-api-1.1.jar
[ERROR] urls[14] = file:/Users/paulsideleau/.m2/repository/com/google/collections/google-collections/1.0/google-collections-1.0.jar
[ERROR] urls[15] = file:/Users/paulsideleau/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm ClassRealm[project>ssi:ssi-pom:4.480.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
import: Entry[import from realm ClassRealm[project>ssi:ssi-pom:4.480.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]

-----------------------------------------------------

at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:180)
... 20 more
Caused by: java.lang.NoSuchFieldError: suppressImportErrors
at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundEnvImpl.<init>(RoundEnvImpl.java:58)
at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:148)
at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:878)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:488)
at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4157)
at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1694)
at org.codehaus.groovy.eclipse.compiler.InternalCompiler.doCompile(InternalCompiler.java:84)
at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.internalCompile(GroovyEclipseCompiler.java:132)
at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.performCompile(GroovyEclipseCompiler.java:90)
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785)
at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
... 20 more
[ERROR]
[ERROR] -----------------------------------------------------
[ERROR] -> [Help 1]

Comment by Kris De Volder [ 09/Jun/14 ]

Please provide a sample project (or multiproject if that be the case). I have no idea where to start on debugging this. But getting a sample to reproduce it is one step in the right direction.

I understand if its hard

I'll have a poke around the stacktraces first. Maybe something obvious will reveal itself.

Comment by Kris De Volder [ 09/Jun/14 ]

Okay... it looks like the problem is that our JDT patch for Eclipse 4.4, which was a snapshot of JDT from a little while ago is missing that field which is referred by the current 'apt' bundle.

The apis must have evolved after the JDT for e44 patch was created.

This is actually not just a problem for the maven support but really indicates a problem in greclipse that might surface even in the IDE use of the compiler.

Note: since I understand the problem now, I don't think you need to go through the trouble of attaching a sample project.

Comment by Kris De Volder [ 09/Jun/14 ]

Raised issue to fix the JDT patch for e4.4
https://jira.codehaus.org/browse/GRECLIPSE-1743

Once that's done can make another attempt at building the maven support.

Comment by Paul Sideleau [ 11/Jun/14 ]

Groovy 2.3.3 has been released.

Comment by Kris De Volder [ 12/Jun/14 ]

Just built / deployed new snapshots of groovy-eclipse-compiler (2.9.0-01) and groovy-eclipse-batch (2.3.3-01).
Please give them a try. See if they work better than the last attempt

Comment by Paul Sideleau [ 13/Jun/14 ]

It worked. All code compiled and all tests passed.

Thank you

Comment by SUKRIT KHERA [ 13/Jun/14 ]

When are we planning to release 2.9.0-01 ? Currently , we are using Java-7 and we want to migrate to Java8.

Comment by Endre Stølsvik [ 17/Jun/14 ]

I would seriously like to be able to work with both Java 8 and Groovy in Eclipse. Is there any estimate on when this will be possible??

Comment by Kris De Volder [ 17/Jun/14 ]

Currently the plan is for around the end of this month.

Comment by Kris De Volder [ 17/Jun/14 ]

To clarify, my previous response was to SUKRIT's question.

> I would seriously like to be able to work with both Java 8 and Groovy in Eclipse. Is there any estimate on when this will be possible??

This is already possible with a snapshot of Greclipse 2.9.0 with the 2.3.3 compiler support, installed into Eclipse 4.4.RC2.

If you want a 'real release' you need to wait for Greclipse 2.9.0 release and Eclipse 4.4 release.

Comment by Endre Stølsvik [ 17/Jun/14 ]

Oh. Thanks. So Eclipse 4.3 support won't happen? (Just checking..)

Comment by Kris De Volder [ 17/Jun/14 ]

The 2.9.0 snapshot currently available does still have an update site which offers the combination of greclipse with Eclipse Java 8 patch for JDT on Eclipse 4.3.
But this "JDT Java 8 patch" really was only a temporary thing to bridge the gap to a proper release of Eclipse 4.4. You can still use that for a while but recommended to move to Eclipse 4.4 if you care about Java 8.

The 4.3 + Java 8 update site is here: http://dist.springsource.org/snapshot/GRECLIPSE/e4.3-j8

Comment by Paul Sideleau [ 27/Jun/14 ]

Do you require any more additional testing to mark this is as fixed?

Thank you

Comment by Kris De Volder [ 27/Jun/14 ]

More testing won't hurt, but its not left open for that.

Its kept open because I will have to do another 'build' of this for the release.
Creating these artifacts is a partially manual process so its not part of a release build automatically.

Once do a 'release' build it would be nice to have someone test the staged artifacts before I push the button to send them to maven central though.

Comment by Paul Sideleau [ 27/Jun/14 ]

I am willing to test the staged artifacts

Comment by Paul Sideleau [ 08/Jul/14 ]

groovy 2.3.4 has been released. Should I create a new JIRA ticket to request support for it and/or is there any documentation on how to create the artifact by hand ?

Thank you

Comment by Kris De Volder [ 10/Jul/14 ]

I've changed the issue title to '2.3.4'. I'll do a snapshot today with the 2.3.4 compiler as I updated the the greclipse compiler yesterday to 2.3.4.

> is there any documentation on how to create the artifact by hand ?

Yes, it is here:
http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+Maven+integration+developer+resources

Process is a bit clunky and error prone. Also before you can do this the greclipse compiler patch has to be updated, but I already did this yesterday.

Comment by Kris De Volder [ 10/Jul/14 ]

2.3.4 batch compiler is now available as a snaphot from codehaus snapshot repo. Please test it

Thanks,

Kris

Comment by Kris De Volder [ 10/Jul/14 ]

PS: I also put new instructions for doing the 'batch artifacts' build here:
https://github.com/groovy/groovy-eclipse/wiki/Building-Maven-Batch-Compiler

Comment by Paul Sideleau [ 10/Jul/14 ]

Looks good. Our project built fine and all tests passed.

Thank you for the quick update and the documentation that you provided.

Comment by Kris De Volder [ 15/Jul/14 ]

Okay thanks. You guys will be the first ones to hear this

The Greclipse 2.9.0 is about ready to release. The build is done and the maven artifacts are also built and staged here:

https://nexus.codehaus.org/content/groups/staging/

Before I press that button to release to maven central, it would be great if someone could test these once more. Paul you up for that?

groovy-eclipse-compiler version: 2.9.0-01
groovy-eclipse-batch-version: 2.3.4-01

If all goes well Greclipse 2.9.0 will release by the end of this week.

Kris

Comment by Paul Sideleau [ 15/Jul/14 ]

Yes, I will be able to test this evening.

Thank you

Comment by Paul Sideleau [ 15/Jul/14 ]

I think we are all set. All classes compiled and all unit tests passed.

Thank you

Comment by Kris De Volder [ 16/Jul/14 ]

Great! Thanks Paul.

Comment by Paul Sideleau [ 17/Jul/14 ]

How soon until this is released to maven central?

Congrats on the release.

Thank you

Comment by Kris De Volder [ 18/Jul/14 ]

I already released the artefacts from codehaus staging to maven central, but it may take some time before they show up.
I would have expected they should be there already now, but it seems they are not (just checked).

If they don't show up in a couple of days maybe something went wrong. So please ping this issue again
to get my attention.

Comment by Kris De Volder [ 18/Jul/14 ]

Actually, it looks like the artefacts are on central already, they just don't show up yet in here http://search.maven.org/
I guess this index takes more time to pick up new artefacts than the actual repository.

But I was able to download new groovy-eclipse-compiler and batch artefacts to my local maven cache from central:

Kris

Comment by Steve Ash [ 18/Jul/14 ]

I tweeted sonatype ops and they are reindexing. They indicated it should be searchable in the next 1-2 hours. https://twitter.com/sonatype_ops/status/490182024431280128

Comment by Denis Murashev [ 07/Nov/14 ]

New versions of artifacts were deployed to staging:
https://nexus.codehaus.org/content/groups/staging/org/codehaus/groovy/groovy-eclipse-batch/2.3.7-01/
https://nexus.codehaus.org/content/groups/staging/org/codehaus/groovy/groovy-eclipse-compiler/2.9.1-01/





[GRECLIPSE-1732] Eclipse using much cpu after sonar plugin analyse is complete Created: 12/May/14  Updated: 13/May/14  Resolved: 12/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Daniel Geißler Assignee: Unassigned
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64
Eclipse Kepler SR2 for JEE Developers


Number of attachments : 0

 Description   

I am using the Sonar Eclipse Plugin from the Marketplace

  • SonarQube Integration for Eclipse Third-Party feature 3.4.0.20140404-0949-RELEASE org.sonar.ide.eclipse.thirdparty.feature.feature.group SonarSource
  • SonarQube Java Analyser 3.4.0.20140404-0949-RELEASE org.sonar.ide.eclipse.jdt.feature.feature.group SonarSource

Every time i trigger a Analysis on a Project with JPA Facets there s a constant workload in the background of Eclipse.

I already read about the Issues with Eclipse JPA Plugin regarding "JPA Java Change Event Handler" and disabled the JPA Validator (also suspended all of them) and the JPA Content Assist.
see http://stackoverflow.com/questions/11631371/why-is-eclipse-juno-4-2-running-jpa-java-change-event-handler-processes

Now the Progress View is empty after "ANALYSIS SUCCESSFUL" and the UI much more responsive but Eclipse is still consuming constant amounts of processor work, while nothing obviously happens.

I'm not sure if this is realy a sonar plugin issue, but by now it s the only plugin that produces this behavior.

Edit: tested with a project of 203 java files and it to basicaly 10min to complete this background operation. Meanwhile Eclipse is not realy useable and closing Eclipse doesn't help too, cause the os process is still there and blocks exactly 1 cpu with 100% load.



 Comments   
Comment by Kris De Volder [ 12/May/14 ]

You should re-raise this issue on the correct project (SONAR, not GRECLIPSE).

Closing as 'Not a Bug' (not a Greclipse bug anyways).

Comment by Daniel Geißler [ 13/May/14 ]

Sorry for raising it in the wrong project.





[GRECLIPSE-1731] @Delegate methodAnnotations parameter not honored when class delegated to comes from dependency Created: 10/May/14  Updated: 09/Dec/14  Resolved: 21/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Jerome Velociter Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Maven 3.2.1


Attachments: Zip Archive delegate-in-dependency-missing-method-annotations.zip    
Number of attachments : 1

 Description   

When delegating to a class from a maven dependency, the "methodAnnotations" parameter of the @Delegate annotation is not honored : the annotations are lost after compilation when this parameter is set to true.

See attached project to reproduce :

  • first build the "dep" project
  • then build the "main" project
  • the @SampleAnnotation is lost on the compiled Bug class


 Comments   
Comment by Denis Murashev [ 14/May/14 ]

It looks like the bug can be reproduced if all classes are in the same project, not only if there is maven dependency.

And it is probably not groovy-eclipse plugin bug, because it can be reproduced without eclipse at all. Just build "dep" and "main" with maven. And then try the following command:
mvn exec:java -Dexec.mainClass="bug.Main"

The result will be:
Found: null

That means the annotation is lost.

Comment by Jerome Velociter [ 14/May/14 ]

The maven build of the test case uses the groovy-eclipse-compiler as groovy compiler. If switched to groovyc with the maven ant-run plugin (as documented here http://groovy.codehaus.org/Compiling+With+Maven2), then the annotation is not lost. With all the classes in the same maven project, and building with maven (with the groovy-eclipse-compiler), then the annotation is not lost either.

Comment by Alex Abdugafarov [ 09/Dec/14 ]

It seems that this fix causes a deadlock in GGTS 3.6.2: https://issuetracker.springsource.com/browse/STS-3980





[GRECLIPSE-1729] Eliminate unused import warning related to JavaDoc Created: 05/May/14  Updated: 21/May/14  Resolved: 21/May/14

Status: Closed
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Illia Khokholkov Assignee: Unassigned
Resolution: Won't Fix  
Labels: maven
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When an import is necessary for JavaDoc only, a warning is generated. Consider the following example:

import java.util.Collections;
import java.util.List;

/**
 * Test class with an {@link Collections import} necessary for JavaDoc only. 
 *
 */
public class Test {
    
    /**
     * The test method. Unused import is related to {@link List}.
     * 
     */
    public void testMethod() {
        
    }
}

The above will result in a couple of warnings related to unused imports when the class is compiled:

[WARNING] ...Test.java:[3,8] 61. WARNING in ...Test.java (at line 3)
    import java.util.Collections;
           ^^^^^^^^^^^^^^^^^^^^^
The import java.util.Collections is never used

[WARNING] ...Test.java:[4,8] 62. WARNING in ...Test.java (at line 4)
    import java.util.List;
           ^^^^^^^^^^^^^^
The import java.util.List is never used

Maven plugin configuration:

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.1</version>
    <executions>
        <execution>
            <id>default-testCompile</id>
            <phase>test-compile</phase>
            <goals>
                <goal>testCompile</goal>
            </goals>
            <configuration>
                <compilerId>groovy-eclipse-compiler</compilerId>
                <source>1.7</source>
                <target>1.7</target>
                <showDeprecation>true</showDeprecation>
                <showWarnings>true</showWarnings>
            </configuration>
        </execution>
        <execution>
            <id>default-compile</id>
            <phase>compile</phase>
            <goals>
                <goal>compile</goal>
            </goals>
            <configuration>
                <compilerId>groovy-eclipse-compiler</compilerId>
                <source>1.7</source>
                <target>1.7</target>
                <showDeprecation>true</showDeprecation>
                <showWarnings>true</showWarnings>
            </configuration>
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.8.0-01</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-batch</artifactId>
            <version>2.1.8-01</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>
    <configuration>
        <compilerId>groovy-eclipse-compiler</compilerId>
        <source>1.7</source>
        <target>1.7</target>
        <showDeprecation>true</showDeprecation>
        <showWarnings>true</showWarnings>
    </configuration>
</plugin>

It would be nice to detect that imports are indeed used, but only in JavaDoc.



 Comments   
Comment by Denis Murashev [ 14/May/14 ]

As far as I know it is normal behavior of Eclipse to add imports for @link JavaDoc tags. And it does not look like specific Groovy-Eclipse plugin issue. So it's probably better to contact Eclipse IDE development team.

Comment by Kris De Volder [ 20/May/14 ]

> As far as I know it is normal behavior of Eclipse to add imports for @link JavaDoc tags

I think that is true, but is it also the case that Eclipse would/should generate warning messages for those imports then?
I don't think eclipse with pure Java does that. If so then this bug is valid since the problem is that the groovy compiler is not aware of the use of the type in Java/Groovy doc.

Comment by Kris De Volder [ 21/May/14 ]

Okay I see now, the error is coming from Maven build rather than Eclipse build. It seems this behavior is indeed consistent then with how Eclipse Java compiler behaves. So I agree with Denis assessment this isn't really bug to fix in Greclipse.
It is rather an inconsistency between how Eclipse <-> maven treats type references in Java / Groovy doc.





[GRECLIPSE-1727] Test suite for traits Created: 30/Apr/14  Updated: 08/Jul/14  Resolved: 08/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Denis Murashev
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Groovy 2.3 adds traits support to groovy, we need some tests to verify they work correctly in groovy eclipse. A spec seems to be here:

http://beta.groovy-lang.org/docs/groovy-2.3.0-SNAPSHOT/html/documentation/core-traits.html

I would recommend some simple tests in GroovySimpleTest and some incremental compilation tests in BasicGroovyBuildTests. These should verify they work and that sensible errors come out when they are used incorrectly.



 Comments   
Comment by Cédric Champeau [ 30/Apr/14 ]

In addition to the specs, you can find more tests here: https://github.com/groovy/groovy-core/blob/master/src/test/org/codehaus/groovy/transform/traitx/TraitASTTransformationTest.groovy

Comment by Andy Clement [ 29/May/14 ]

The first big PR from Denis is in, I think he is going to add a few incremental compilation tests (as opposed to batch compilation tests) and then we are done.

Comment by Andy Clement [ 30/May/14 ]

Second PR is in, which included incremental tests.

Comment by Kris De Volder [ 27/Jun/14 ]

I am reopening it because last pull request had to be reverted because of using Eclipse 4.4 only API.

There's a new pull request from Denis here:

https://github.com/groovy/groovy-eclipse/pull/57

Comment by Pascal Schumacher [ 08/Jul/14 ]

Pull request was merged, so I guess this could be closed?





[GRECLIPSE-1725] Eclipse hangs on code assist Created: 15/Apr/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Alex Boyko Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The problem can be reproduce in GGTS 3.5.0 e43j8 and described by the code snippet below.
List<String> myList = new ArrayList<String>()
myList.each

{ it.trim() }

myList.sort

{ a, b -> a.trim() <=> b.trim() }
myList.sort { a, b -> a.trim() <=> b.trim() }

.each

{ it // code assist hangs after '.' is typed }




[GRECLIPSE-1724] A lot of tests fail on Windows setup Created: 15/Apr/14  Updated: 08/Jul/14  Resolved: 08/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Vasiliy Kizhaev Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Number of attachments : 0

 Description   

There are 244 tests from 'AllGroovyTests' that fail on Windows platform.



 Comments   
Comment by Alex Boyko [ 22/Apr/14 ]

The fix was https://github.com/groovy/groovy-eclipse/pull/29
Are there any tests left not passing on Win?

Comment by Vasiliy Kizhaev [ 23/Apr/14 ]

Yes, three tests left: one is about key bindings conflicts on startup and another two are about line wrappings, for example, if you format this piece of code

def gender = ["unknown",
"female",
"male"]

it is expected to get

def gender = ["unknown", "female", "male"]

but what you really get is

def gender = [
	"unknown",
	"female",
	"male"
]

This behavior takes place not only in tests, but in the application too.

Here are the names of the failing tests:
ErrorLogTest#testNoWarningsOnStartup()
Formatter_Test_List_formatting_bug_827.txt
Formatter_Test_List_formatting_for_fields.txt

Comment by Vasiliy Kizhaev [ 08/Jul/14 ]

Pull request successfully merged https://github.com/groovy/groovy-eclipse/pull/60





[GRECLIPSE-1723] Immutable containing Immutable field from other maven module Created: 14/Apr/14  Updated: 24/Jun/14  Resolved: 24/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Jan Bols Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive immutableTest.zip    
Number of attachments : 1

 Description   

Hi,
I'm using an @Immutable class containing a field of an @Immutable class defined in another maven module.

If I don't specify it in the list of knownImmutableClasses, it does not
compile due to the following reason:

*SomeValueObject.groovy: -1 Groovy:@Immutable processor doesn't know how to handle field 'id' of type 'SomeId' while compiling class SomeValueObject. *

class in maven module mod1:

import groovy.transform.Immutable
@Immutable
class SomeId{
    UUID id
}

class in maven module mod2

import groovy.transform.Immutable
@Immutable
//(knownImmutableClasses = [SomeId])
class SomeValueObject{
    SomeId id
}

Any ideas of why this happens?
groovy is build using groovy-eclipse-compiler:

                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>${compiler-plugin.version}</version>
                    <inherited>true</inherited>
                    <configuration>
                        <compilerId>groovy-eclipse-compiler</compilerId>
                        <source>1.6</source>
                        <target>1.6</target>
                        <encoding>utf-8</encoding>
                    </configuration>
                    <dependencies>
                        <dependency>
                            <groupId>org.codehaus.groovy</groupId>
                            <artifactId>groovy-eclipse-
compiler</artifactId>
                            <version>2.8.0-01</version>
                        </dependency>

                        <dependency>
                            <groupId>org.codehaus.groovy</groupId>
                            <artifactId>groovy-eclipse-batch</artifactId>
                            <version>2.1.8-01</version>
                        </dependency>
                    </dependencies>
                </plugin>

and version 2.1.8 of groovy is used.

I tried this running maven 3.2.1, but also using maven 2.2.1.
I attached a zip file containing a small maven setup.
I also tried running this with gradle and that worked.

Best regards
Jan






[GRECLIPSE-1722] Support Groovy 2.3 Created: 10/Apr/14  Updated: 10/Apr/14  Resolved: 10/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Marked 'major' because 2.3 is required for groovy to behave properly on Java8.



 Comments   
Comment by Andy Clement [ 10/Apr/14 ]

Fix commit of org.codehaus.groovy23 has been made - based on 2.3.0-beta-1 tag.





[GRECLIPSE-1721] Java 8 patch issues? Created: 03/Apr/14  Updated: 12/May/14  Resolved: 12/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Unassigned
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I can't reproduce this now but I got this worrysome exception when doing code completion for a type in a Grails project. Looks like something trying to organize imports crashed by using API that has been changed in JLS8 AST.

java.lang.UnsupportedOperationException: Operation only supported in JLS8 and later AST
	at org.eclipse.jdt.core.dom.ASTNode.unsupportedIn2_3_4(ASTNode.java:1968)
	at org.eclipse.jdt.core.dom.AnnotatableType.annotations(AnnotatableType.java:99)
	at org.eclipse.jdt.internal.corext.codemanipulation.ImportReferencesCollector.visit(ImportReferencesCollector.java:203)
	at org.eclipse.jdt.core.dom.SimpleType.accept0(SimpleType.java:197)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
	at org.eclipse.jdt.internal.corext.codemanipulation.ImportReferencesCollector.doVisitNode(ImportReferencesCollector.java:185)
	at org.eclipse.jdt.internal.corext.codemanipulation.ImportReferencesCollector.visit(ImportReferencesCollector.java:420)
	at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:611)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
	at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:470)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
	at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:214)
	at org.codehaus.jdt.groovy.core.dom.GroovyCompilationUnit.accept0(GroovyCompilationUnit.java:39)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
	at org.eclipse.jdt.internal.corext.codemanipulation.ImportReferencesCollector.collect(ImportReferencesCollector.java:68)
	at org.eclipse.jdt.internal.corext.codemanipulation.ImportReferencesCollector.collect(ImportReferencesCollector.java:62)
	at org.eclipse.jdt.internal.corext.codemanipulation.ContextSensitiveImportRewriteContext.getImportedNames(ContextSensitiveImportRewriteContext.java:226)
	at org.eclipse.jdt.internal.corext.codemanipulation.ContextSensitiveImportRewriteContext.findInContext(ContextSensitiveImportRewriteContext.java:99)
	at org.eclipse.jdt.core.dom.rewrite.ImportRewrite.internalAddImport(ImportRewrite.java:941)
	at org.eclipse.jdt.core.dom.rewrite.ImportRewrite.addImport(ImportRewrite.java:788)
	at org.eclipse.jdt.internal.ui.text.java.LazyJavaTypeCompletionProposal.computeReplacementString(LazyJavaTypeCompletionProposal.java:138)
	at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.getReplacementString(LazyJavaCompletionProposal.java:331)
	at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:367)
	at org.eclipse.jdt.internal.ui.text.java.LazyJavaTypeCompletionProposal.apply(LazyJavaTypeCompletionProposal.java:203)
	at org.eclipse.jdt.internal.ui.text.java.LazyGenericTypeProposal.apply(LazyGenericTypeProposal.java:268)
	at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:497)
	at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.apply(LazyJavaCompletionProposal.java:489)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertProposal(CompletionProposalPopup.java:940)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertSelectedProposalWithMask(CompletionProposalPopup.java:891)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.verifyKey(CompletionProposalPopup.java:1323)
	at org.eclipse.jface.text.contentassist.ContentAssistant$InternalListener.verifyKey(ContentAssistant.java:808)
	at org.eclipse.jface.text.TextViewer$VerifyKeyListenersManager.verifyKey(TextViewer.java:491)
	at org.eclipse.swt.custom.StyledTextListener.handleEvent(StyledTextListener.java:65)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1416)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1401)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1187)
	at org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5954)
	at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5636)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1416)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1401)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1428)
	at org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:829)
	at org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:3236)
	at org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:758)
	at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2096)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:5467)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4569)
	at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
	at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8756)
	at org.eclipse.swt.widgets.Display.eventProc(Display.java:1243)
	at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
	at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2302)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3361)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:140)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:611)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1426)


 Comments   
Comment by Kris De Volder [ 03/Apr/14 ]

In case it helps this the code where I got the error (although I only got it once and can't reproduce it now).

package mojoa

import grails.transaction.Transactional
import groovy.json.JsonBuilder



@Transactional
class FooService {

    def gogog() {
		def builder = new JsonBuilder()
		builder.person {
			name "Kris"
			lastName "De Volder"
		}
		return builder.content.toString()
    }
}

The error happened when completing 'JsonBuilder'.





[GRECLIPSE-1720] java.util.EmptyStackException from TypeInferencingVisitorWithRequestor when using CompileStatic Created: 02/Apr/14  Updated: 08/Apr/14  Resolved: 08/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.9.0.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jesper Steen Møller Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Using a build from source off GitHub, based on E4.3SR2.
Using the Groovy 2.1.x compiler.


Number of attachments : 0

 Description   

Given this code:

import groovy.transform.CompileStatic

@CompileStatic
public class Bug {
enum Letter

{ A,B,C }

boolean bug(Letter l)

{ boolean isEarly = l in [Letter.A,Letter.B] isEarly }

}

I get this exception:

Error in inferencing engine for Bug.groovy

!STACK

0

java.util.EmptyStackException
at java.util.Stack.peek(Stack.java:102)
at java.util.Stack.pop(Stack.java:84)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitTernaryExpression(TypeInferencingVisitorWithRequestor.java:1759)
at org.codehaus.groovy.ast.expr.TernaryExpression.visit(TernaryExpression.java:43)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBinaryExpression(TypeInferencingVisitorWithRequestor.java:980)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitDeclarationExpression(TypeInferencingVisitorWithRequestor.java:1427)
at org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:86)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:71)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:236)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:37)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:206)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1332)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:103)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:114)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstructorOrMethod(TypeInferencingVisitorWithRequestor.java:818)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:549)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:382)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:330)
at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:112)
at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

The root cause is that org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBinaryExpression(BinaryExpression) returns quickly from the CompareToNullExpression expressions injected by the CompileStatic AST, and so doesn't leave a type on the stack for the outer type analysis/inference.

A crude fix is to do replace "if (node.getEnd() == 0)" with
"if (node.getEnd() == 0 && !(node instanceof CompareToNullExpression))"

but I'm sure that wouldn't be a complete fix.

Perhaps the CompileStatic AST should have (different) way of marking its nodes so the inferencer can deal with them in a predictable manner.

This is using the 2.1.x compiler.



 Comments   
Comment by Alex Boyko [ 08/Apr/14 ]

Resolved in 2.9.1... GGTS 3.5.1





[GRECLIPSE-1719] Compilation error when using @AnnotationCollector Created: 26/Mar/14  Updated: 05/Oct/14  Resolved: 08/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.8.0.Release, 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Critical
Reporter: Kris De Volder Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive annotationcollector.zip    
Number of attachments : 1

 Description   

This problem comes from Jeff Brown. I'm attaching a small test project he gave me.

Inport the sample (using gradle tooling is easiest since it consists of two separate projects, one depends on the other).

You will see a error in the problems view that
'MyAnnotation can't be converted to Annotation' in 'Widget.groovy'.

I also get the same error if I move the code into a single project.

What seems to be going on is that the annotation 'MyAnnotation' is a bit special. It is supposed to trigger an AST tranform that removes the annotation itself and replaces it with other annotations (so the annotation is like an alias for a group of other ones).

This functionality actually seems to work just fine. I.e. if we ignore the error and inspect the .class files it looks like the results are correct.

The problem is that some part of JDT is doing a check that 'MyAnnotation' has the 'annotation bit' set. But it does not and it also doesn't extend the usual Annotation class but instead extends groovy.Object. Thus it fails JDTs 'isAnnotion' check and causes a type error.

I grabbed a stack trace at the location where the error is reported:

Daemon Thread [Compiler Processing Task] (Suspended (breakpoint at line 721 in org.eclipse.jdt.internal.compiler.ast.Annotation))	
	org.eclipse.jdt.internal.compiler.ast.MarkerAnnotation(org.eclipse.jdt.internal.compiler.ast.Annotation).resolveType(org.eclipse.jdt.internal.compiler.lookup.BlockScope) line: 721	
	org.eclipse.jdt.internal.compiler.ast.ASTNode.resolveAnnotations(org.eclipse.jdt.internal.compiler.lookup.BlockScope, org.eclipse.jdt.internal.compiler.ast.Annotation[], org.eclipse.jdt.internal.compiler.lookup.Binding, boolean) line: 896	
	org.eclipse.jdt.internal.compiler.ast.ASTNode.resolveAnnotations(org.eclipse.jdt.internal.compiler.lookup.BlockScope, org.eclipse.jdt.internal.compiler.ast.Annotation[], org.eclipse.jdt.internal.compiler.lookup.Binding) line: 766	
	org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.getAnnotationTagBits() line: 966	
	org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.faultInTypesForFieldsAndMethods() line: 844	
	org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitScope(org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope).faultInTypes() line: 525	
	org.eclipse.jdt.internal.compiler.Compiler.process(org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration, int) line: 821	
	org.eclipse.jdt.internal.compiler.ProcessTaskManager.run() line: 137	
	java.lang.Thread.run() line: 744


 Comments   
Comment by Kris De Volder [ 26/Mar/14 ]

Jeff's sample projects.

Comment by Kris De Volder [ 08/May/14 ]

Raised priority to critical based on input from Jeff Brown: "It is a big deal for anyone who wants to build a Grails 2.4 app in the IDE and wants to use @GrailsCompileStatic (or any other annotation marked with @AnnotationCollector)."

Related issues:

Comment by Kris De Volder [ 08/May/14 ]

Previously I mentioned "I also get the same error if I move the code into a single project.".
As I am trying to reproduce again, this is not true (any more?).

I need the annotation to be defined in a separate project to get the error message.
Seems consistent with: GRECLIPSE-1679

Comment by Kris De Volder [ 08/May/14 ]

I pushed a fix.
The fix is applied to e43j8 and e44 versions of JDT patch only.

Comment by Lari Hotari [ 03/Oct/14 ]

This fixes the compilation error, but I now have a problem that I loose imports for AnnotationCollector annotation classes when I do organize imports. Auto-importing those classes don't work either. It's easy to reproduce the problem with groovy.transform.CompileDynamic annotation.

Comment by Kris De Volder [ 03/Oct/14 ]

Please create a new issue ticket for this and include a code example to reproduce.

Comment by Lari Hotari [ 05/Oct/14 ]

I reported GRECLIPSE-1794





[GRECLIPSE-1718] Clean/Build introducing transient errors in other projects Created: 11/Mar/14  Updated: 15/May/14  Resolved: 15/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive SampleProject_JIRA-1718.zip    
Number of attachments : 1

 Description   

Jeff reports:

  • latest greclipse
  • building grails core, the 2.3.X branch

Cleaning grails-bootstrap introduces errors in *-plugin-rest and grails-test-suite-uber. Then cleaning *-plugin-rest fixes everything. The error in *-plugin-rest is the one to look into.



 Comments   
Comment by Alex Boyko [ 13/Mar/14 ]

It looks to me that the issue is that Greclipse IDE is not showing the issue in the problems view, i.e. not creating a resource marker and such rather than erroneously showing a problem after a project clean. The error is there even if all projects are cleaned or the rest project is cleaned. The difference is that it's not shown in the problems view and there are no error annotations on the Groovy resource.

In AbstractLinkingRenderer.groovy:

"Renderer<T> htmlRenderer" should be there rather than "Renderer htmlRenderer" for the htmlRenderer variable declaration. The Groovy syntax error seems legitimate to me.

The code should be:
final void render(T object, RenderContext context) {
final mimeType = context.acceptMimeType ?: getMimeTypes()[0]
context.setContentType( GrailsWebUtil.getContentType(mimeType.name, encoding) )

def viewName = context.viewName ?: context.actionName
final view = groovyPageLocator?.findViewForFormat(context.controllerName, viewName, mimeType.extension)
if (view) {
// if a view is provided, we use the HTML renderer to return an appropriate model to the view
Renderer<T> htmlRenderer = rendererRegistry?.findRenderer(MimeType.HTML, object)
if (htmlRenderer == null)

{ htmlRenderer = new DefaultHtmlRenderer(targetType) }

htmlRenderer.render(object, context)
} else

{ renderInternal(object, context) }

}

Comment by Alex Boyko [ 14/Mar/14 ]

Looks like the syntax error is erroneous rather than problem marker not created.
The workaround for the issue is still Renderer<T> htmlRenderer
Couldn't create a minimal sample code to reproduce the problem. Created something very similar but the syntax error is not generated.

Observations:

1) If the following if block is commented out than syntax error is gone.
if (htmlRenderer == null)

{ htmlRenderer = new DefaultHtmlRenderer(targetType) }

Has to do something with Renderer htmlRenderer declaration line and htmlRenderer conditional assignment to DefaultHtmlRenderer.

2) MethodExpressionCall for "htmlRenderer.render(object, context)" has
Compilation: GenericsType is ImmutableClassNode for java.lang.Object (works in this case)
Reconcile: GenericsType is ClassNode for java.lang. Object that has a redirect to ImmutableClassNode for java.langObject - Syntax Error generated in this case

Comment by Alex Boyko [ 17/Mar/14 ]

Problematic is static compilation that is triggered by the presence of @CompileStatic annotation on the AbstractLinkingRenderer class. Seems like static compilation generates the groovy syntax error erroneously. Furthermore, if static compilation produces an error the problem marker is created only for the resource modification.

Comment by Alex Boyko [ 17/Mar/14 ]

Removing @CompileStatic annotation would also be a workaround.

Comment by Andy Clement [ 17/Mar/14 ]

It isn't uncommon for that to be a workaround. It does suggest that the ClassNodes being built by us just don't match those that groovy would be building in the same circumstance. If you had a reproduceable compile setup I'd say compile it inside and outside of eclipse (command line), debug both and compare the data structures involved to spot the difference. I'm still suspicious of that code that copies the groovy Java5 type behavior.

Comment by Eduardo Simioni [ 26/Mar/14 ]

I'm not entirely sure that this issue is the same that I have, so I thought of commenting here to check first instead of raising a new issue.
I have a problem running the latest GA versions of Kepler or STS with latest Groovy plugin from Eclipse Marketplace.

I have a workspace with a single Groovy project and a bunch of Java projects. Two of those Java projects also have aspects and use the AspectJ nature. They are all maven projects, configured in Eclipse automatically with m2e and the Spring AspectJ Configurator.

When I first install Groovy plugin, everything works fine for a couple of days, I don't know exactly which event triggers the problem, but after that my projects that have AsepctJ nature stop outputting compiled classes to target/classes folder, in fact they seem not to compile anything at all to any folder, target/classes is always empty.
When I look at the project configuration everything seems to be fine with the Java Build Path and target output folders.

When I remove the Groovy plugin they start compiling as expected again. Once more, the projects that start having problems DO NOT have Groovy nature, only Java and AspectJ natures.

Please let me know if this should be a separate issue.

Comment by Alex Boyko [ 26/Mar/14 ]

Think what you've described is a different issue from this one. This one is a static compile issue. Noticing this issue is a bit difficult because the error marker isn't always created for Groovy syntax error occurred during the static compilation. Yet the error is always there and can be observed once the groovy file is opened in an editor
Your issue is something rather different. I'd recommend you creating a sample little project on which the issue can be reproduced and attaching this project to the JIRA. Eclipse, Groove Eclipse, Groovy compiler and Java versions would be important to know too.

Comment by Alex Boyko [ 15/May/14 ]

Turns out that our Groovy version for Groovy-Eclipse requires changes made to ClassNode in Groovy 2.x
https://github.com/groovy/groovy-eclipse/pull/44
Tested with Grails-Core, sample projects and Greclipse unit tests. Ran build locally and installed into Eclipse 4.3.2 and STS 3.5.1 via a local update site and performed the tests above.

Comment by Alex Boyko [ 15/May/14 ]

Delivered the fix for 2.9.0





[GRECLIPSE-1717] Java/Groovy not compiling with generics error Created: 11/Mar/14  Updated: 12/Mar/14  Resolved: 12/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Reported by Jeff (in grails codebase):

groovy file:

class SomeGroovyHelper {
    static <T> List<T> doit(Class<T> factoryClass, ClassLoader classLoader = SomeGroovyHelper.class.classLoader) {
        null
    } 
}

java file:

public class Demo {

    public void someMethod() {
        SomeGroovyHelper.doit(String.class, null);
    }
}  

shows error:
"The method doit(Class<T>, ClassLoader) from the type SomeGroovyHelper refers to the missing type T"

Removing the default value for the parameter in the groovy method seems to fix it (which points at a possible area to explore first).



 Comments   
Comment by Alex Boyko [ 12/Mar/14 ]

PR for the issue: https://github.com/groovy/groovy-eclipse/pull/18

Comment by Andy Clement [ 12/Mar/14 ]

PR committed. Testcase added too BasicGroovyBuildTests.

Comment by Andy Clement [ 12/Mar/14 ]

Fixed!





[GRECLIPSE-1716] Error messages dropped in maven compiler Created: 07/Mar/14  Updated: 11/Mar/14  Resolved: 11/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jared Bunting Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File error_msg_fix.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

When running a maven build, there are some issues with the error messages. The most glaring is that the last message is always dropped. It still registers, and the compile fails, but the error itself is never output. The other is simply that when the error messages are reconstituted new lines are left out, causing some poorly formatted errors.

I am attaching a patch that address this.



 Comments   
Comment by Alex Boyko [ 08/Mar/14 ]

Can you please fork this repository git repository https://github.com/groovy/groovy-eclipse and submit your patch as a pull request? This way based on your contributions you could become a committer.

Comment by Alex Boyko [ 11/Mar/14 ]

Your patch has been delivered.

Comment by Jared Bunting [ 11/Mar/14 ]

Sorry, I was intending to create the pull request - just a busy week. If pull requests are the preferred mechanism for patches, I will certainly do that in the future.





[GRECLIPSE-1715] Smart tab fails for all lines after a String with unescaped dollar sign Created: 04/Mar/14  Updated: 07/Mar/14  Resolved: 07/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Critical
Reporter: Adam Steiner Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File Bug.groovy     Text File Eclipse Config.txt     Text File Event Details.txt    
Number of attachments : 3

 Description   

To reiterate, the Tab key becomes UNUSABLE after the erroneous string.
See Summary, attached code and attached Stack Trace.



 Comments   
Comment by Alex Boyko [ 05/Mar/14 ]

Hmm... for some reason I'm not getting issue... I've tried GGTS 3.5 RC1 and the corresponding dev environment... all on 4.3.2 Kepler... Doesn't seem like i'm getting it.

I saw this though:
java.lang.NullPointerException
at org.codehaus.groovy.antlr.parser.GroovyLexer.require(GroovyLexer.java:300)
at org.codehaus.groovy.antlr.parser.GroovyLexer.mSTRING_CTOR_END(GroovyLexer.java:2364)
at org.codehaus.groovy.antlr.parser.GroovyLexer.mSTRING_LITERAL(GroovyLexer.java:2028)
at org.codehaus.groovy.antlr.parser.GroovyLexer.nextToken(GroovyLexer.java:459)
at org.codehaus.groovy.antlr.parser.GroovyLexer$1.nextToken(GroovyLexer.java:249)
at org.eclipse.jdt.groovy.core.util.GroovyScanner.nextToken(GroovyScanner.java:60)

after pressing enter at the end of the line, but this is unlikely to be critical, but a minot annoyance. I doubt however that what I'm seeing is the same as the reported issue.

Can you clarify perhaps the instructions on reproducing this problem? I've tried pressing 'Enter/Return' key right after the comma in '~"(?i)^sometext$", and was hoping to get a failure on putting an indent before the next string, but string is offset correctly. Tried writing groovy code outside of 'doThis(XXX) and the indent is such that everything is aligned with parameters of doThis. Is that the issue? (Not getting the same exception though)

Comment by Adam Steiner [ 06/Mar/14 ]

I'm using Eclipse Java EE IDE for Web Developers, Kepler 4.3.2, with the Groovy-Eclipse plugin installed.

Create a new Groovy Project, Add "Bug.groovy" to the project.
Any line below '~"(?i)^sometext$", // SMART TAB FAILS AFTER HERE.' is where the tabbing fails.

Apologies, I'm used to posting in the Eclipse Bug System, where the Eclipse Config file is everything you need to know about a user's environment.

Comment by Kris De Volder [ 06/Mar/14 ]

Alex pull request merged. Closing issue.
https://github.com/groovy/groovy-eclipse/pull/12

Comment by Alex Boyko [ 06/Mar/14 ]

Adam, would you mind checking the code out of from Groovy Eclipse Git: https://github.com/groovy/groovy-eclipse/ and see if this issue is fixed there for you? Thanks in advance.

Comment by Alex Boyko [ 07/Mar/14 ]

Please try Groovy Eclipse from this update site here: http://dist.springsource.org/release/GRECLIPSE/e4.3/ See if this issue is resolved.

Comment by Adam Steiner [ 07/Mar/14 ]

Yes, that worked. Using Groovy-Eclipse Feature 2.9.0.xx-20140307-1300-e43-SNAPSHOT from the SHAPSHOT. The Release url is still on 2.8.0.

Thanks!





[GRECLIPSE-1713] Test failures Created: 03/Mar/14  Updated: 04/Mar/14  Resolved: 04/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

GroovyJDTTests was passing for me but there is more to run than that.ConstructorCompletionTests is failing as is TypeCompletionTests2.



 Comments   
Comment by Andy Clement [ 04/Mar/14 ]

All fixed up. Combination of two things:

  • source location processing for type annotations was not coping with synthetic arguments
  • some 'smarts' in the content assist proposal computation was adding in the ';' if it looks like nothing could follow the selection. We don't want that for groovy.




[GRECLIPSE-1712] Upgrade to Java8 Created: 03/Mar/14  Updated: 03/Mar/14  Resolved: 03/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Need to upgrade the JDT patch that is in Groovy-Eclipse to patch the Eclipse Java8 compiler.



 Comments   
Comment by Andy Clement [ 03/Mar/14 ]

Done. The first pass is to a JDT core that is not quite their RC2 - so we'll need to do another pass to pick up the latest fixes before release.

Possibly serious change due to this I had to prevent some of the tidyup for lookupenvironment/typesystem because some of the content assist type inference code is using it after it would normally have been tidied away. I'm assuming although tidyup doesn't happen it will be GC'd later when orphaned.





[GRECLIPSE-1711] Groovy 2.2.2 Compiler Support Created: 26/Feb/14  Updated: 05/Jun/14  Resolved: 05/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Kris De Volder Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Groovy 2.2.2 is or is about to be released. We should update the groovy compiler in Greclipse to the latest version.



 Comments   
Comment by Kris De Volder [ 26/Feb/14 ]

I have done the patch since 2.2.0, first pulling in changes from Groovy core from 2.2.0 -> 2.2.1 and then from 2.2.1 -> 2.2.2.
This is just waiting for a final review when any potential last minute changes from 'upstream' when Groovy 2.2.2 is officially released.

Comment by Kris De Volder [ 26/Feb/14 ]

Groovy 2.2.2 is now official:
http://groovy.329449.n5.nabble.com/ANN-Groovy-2-2-2-td5718598.html





[GRECLIPSE-1710] Compile with Groovy 2.2.X Created: 14/Feb/14  Updated: 15/May/14  Resolved: 15/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Paul Sideleau Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Please add support to compile with groovy 2.2.x

Thank you.






[GRECLIPSE-1709] An outline is not available Created: 03/Feb/14  Updated: 15/May/14  Resolved: 15/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Minor
Reporter: Mark Lehky Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows, Linux
Eclipse: Build id: 20130919-0819
Groovy-Eclipse plugin: Version: 2.8.0.xx-20130703-1600-e43-RELEASE


Number of attachments : 0

 Description   

For an open class, in the Outline view, I only get the message "An outline is not available."

I have read the FAQ answer here: <http://groovy.codehaus.org/Eclipse+Plugin+FAQ#EclipsePluginFAQ-Q.WhenIloadaGroovyfile,whyistheoutlineviewblank?>, however this is not useful.

My class does not have any errors: it compiles with no errors (or warnings), and runs just fine.
Further, in the Package Explorer view the outline of the class is available. Also, in the quick outline view Ctrl-O the outline is available as well.



 Comments   
Comment by Mark Lehky [ 03/Feb/14 ]

Might be worth pointing out: for pure Java class, the Outline view works just fine.

Comment by Andy Clement [ 03/Feb/14 ]

I think it is worth trying a greclipse dev build - we had this problem with an empty outline a while ago, I'm just not sure if the fix made it into 2.8.0 or not.

Comment by Mark Lehky [ 04/Feb/14 ]

I installed Version: 2.9.0.xx-20140116-1400-e43-RELEASE from http://dist.springsource.org/snapshot/GRECLIPSE/e4.3/ That seems to have fixed the problem.
How do I know when this will make it into the stable release. I generally do not need the cutting edge stuff, I just need my stuff to work. :-\
Thanx!





[GRECLIPSE-1706] "Assign statement to new local variable" quick fix not available within closures Created: 30/Jan/14  Updated: 07/Mar/14  Resolved: 07/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.9.0.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Davide Cavestro Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy-Eclipse plugin

Version: 2.9.0.xx-20131205-1200-e43-RELEASE
Groovy version: org.codehaus.groovy


Number of attachments : 0

 Description   
Steps to reproduce
  1. select a statement within a closure
  2. open the quick fix/assist contextual menu (CTRL+1)
Actual behavior

The Assign statement to new local variable action is missing, but if I do the same outside the closure the action is available and works fine.

Expected behavior

I'd expect to have the Assign statement to new local variable action available

Follows a snippet triggering the right and the wrong behavior

Foo.groovy
class Foo {

    def foo () {
        // RIGHT: selecting the entire statement on the next row the "Assign to new variable" action is available
        'foo'.indexOf('qwerty')     
        
        def myClosure = {
            // WRONG no "Assign to new variable" action
            'foo'.indexOf('qwerty') 
        }
    }
}


 Comments   
Comment by Davide Cavestro [ 30/Jan/14 ]

Please also note that when the closure is passed to a method (i.e. using each) on a method defined without the def keyword, then the action is available, but it lead to wrong results (it could be related to GRECLIPSE-1526).
If the closure is within a method defined with the_def_ keyword, then the action is not available.
Follows an example

Foo2.groovy
class Foo {
    public void foo () {
        ['foo'].each {String s->
            s.bytes //  "Assign to new variable" action is available, but if used lead to wrong result
        }

// This would be the result of running "Assign to new variable" on the above statement 

//      def each = ['foo'].each {String s->
//          s.bytes //  "Assign to new variable" action is available, but if used lead to wrong result
//      }
    }
    
    def bar () {
        ['bar'].each {String s->
            s.bytes  // WRONG no "Assign to new variable" action (the method is defined with the "def" keyword)
        }
    }
}





[GRECLIPSE-1703] Method binding depending on declaration order Created: 28/Jan/14  Updated: 01/Sep/14  Resolved: 08/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following Java class:

Utility.java
package a;

import java.util.ArrayList;
import java.util.Collection;
import java.util.List;

public class Utility {

	public static List<MyExtObject> list(){
		return new ArrayList<MyExtObject>();
	}

	public static <T extends MyObject> boolean remove(Collection<? extends T> collection, MyObject obj) {
		return collection.remove(obj);
	}

	public static <T extends MyObject> int remove(List<? extends T> list, MyObject obj) {
		final int i = list.indexOf(obj);
		if (i != -1)
			list.remove(i);
		return i;
	}
	
	public static class MyObject {}
	
	public static class MyExtObject extends MyObject {}
}

and the following Groovy class:

Test2.groovy
package a

import a.Utility.MyObject

class Test2 {
  void doSomething() {
	  def a = Utility.list()
	  def b = Utility.list()
	  a.remove(Utility.remove(b, new MyObject()))
  }
}

Put the cursor over Utility.remove(...) method name in Test2.groovy and hit F2 to show the Javadoc. This is what is shown:

Boolean a.Utility.remove(Collection<Object> collection, MyObject obj)

Apart from the wrong return type (see GRECLIPSE-1702), the method which is actually invoked, instead, is this one:

int a.Utility.remove(List<Object> list, MyObject obj)

If you press F3, the IDE leads you to the wrong method, too.

Please note that, if you change Utility.java and swap the declaration order of the two remove(...) overloadings, the type inferencing is correct instead.



 Comments   
Comment by Vasiliy Kizhaev [ 12/May/14 ]

This issue is quite similar to GRECLIPSE-1702 and they seem to have common solution.

Comment by Vasiliy Kizhaev [ 08/Jul/14 ]

Fixed by the following PR: https://github.com/groovy/groovy-eclipse/pull/56

Comment by Mauro Molinari [ 08/Jul/14 ]

Great news, thank you!

Comment by Mauro Molinari [ 01/Sep/14 ]

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!





[GRECLIPSE-1702] Primitive type return type detected as wrapper type Created: 28/Jan/14  Updated: 01/Sep/14  Resolved: 08/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following Java class:

Utility.java
package a;

import java.util.List;

public class Utility {

	public static int remove(List<?> list, Object obj) {
		final int i = list.indexOf(obj);
		if (i != -1)
			list.remove(i);
		return i;
	}
}

and the following Groovy class:

Test1.groovy
package a

class Test1 {
  void doSomething() {
	  List a = new ArrayList()
	  List b = new ArrayList()
	  a.remove(Utility.remove(b, new String()))
  }
}

Put the cursor over Utility.remove(...) method name in Test1.groovy and press F2 to show the Javadoc. This is what is shown:

Integer a.Utility.remove(List<Object> list, Object obj)

Instead, I would expect:

int a.Utility.remove(List<Object> list, Object obj)

The consequence, in this specific example, is that if you put the cursor over a.remove(...) in Test1.groovy and press F2, you'll see that GRECLIPSE is considering the wrong method:

Boolean java.util.List.remove(Object o)

while the method actually invoked is:

Object remove(int index)

If you press F3, the IDE will lead you to the wrong method declaration, too.



 Comments   
Comment by Alex Boyko [ 07/Mar/14 ]

The problem is also that SimpleTypeLookup doesn't take into account the parameter types and as a result doesn't differentiate between these 2 methods:
void foo(int a)
void foo(String s)

Regardless the parameter type the first found method is returned based on the criterias:
1) method name
2) return type
3) number of parameters
(Fixing this results in a number of things broken )

Fixing the initial problem of getting Integer remove(...) vs int remove(...) can be fixed in TypeLookupResult constructor by commenting out "ClassHelper.isPrimitiveType(type) ? ClassHelper.getWrapper(type)" This, however, results in a number of unit tests failures.

Looks like something not easy to fix before the release

Comment by Vasiliy Kizhaev [ 12/May/14 ]

The problem is also that SimpleTypeLookup doesn't take into account the parameter types and as a result doesn't differentiate between these 2 methods:
void foo(int a)
void foo(String s)

I've tried make SimpleTypeLookup to take parameter types into account. It seems like this is a huge problem.
Firstly, I made findMethodDeclaration(String name, ClassNode declaringType, List<ClassNode> methodCallArgumentTypes, boolean checkSuperInterfaces) to return method that has exactly the same parameter types as the call in case of exact types match was found. Even this seemingly obvious fix implied a lot of tests failures. Plenty of them fail because TypeInferencingVisitorWithRequestor gets incorrect code to be processed.
For example, let us assume we have a Groovy class:

class LotsOfMethods {
	def meth() {
	}
	def meth(int a) {
	}
	def meth(String a, LotsOfMethods b) {
	}
}
	new LotsOfMethods().meth(1)
	new LotsOfMethods().meth("", null)
	new LotsOfMethods().meth()

It is expected have three method calls inside Object run() method during code processing performed by TypeInferencingVisitorWithRequestor.visitJDT(IType type, ITypeRequestor requestor), but somehow there are only the first two method calls presented. As a result, we get the FindOccurencesTest.testOverloaded1() test failure.

After the first step I was planning go further and to implement method finder as it is described in Java Language Specifications but that doesn't seem to make any sense before the problems described above are not resolved.

All the code modifications related to this issue can be found here: https://github.com/kizhaevv/groovy-eclipse/compare/GRECLIPSE-1702
There is another issue that is related to this one: http://jira.codehaus.org/browse/GRECLIPSE-1703

Comment by Alex Boyko [ 12/May/14 ]

I think the progress on this issue has been good actually. The fact that a lot of tests fail with the fix for this simply implies that a number of other places in Groovy Eclipse code base need to be adjusted (I came to the same conclusion). Consequently, this work seems to be a feature work rather than just a defect fix and will take some considerable time.

Comment by Kris De Volder [ 12/May/14 ]

> After the first step I was planning go further and to implement method finder as it is described in Java Language Specifications...

That seems like a good thing to do, but it may be a lot of work.

The 'quick fix' which only looks at exact matches if they exist and falls back on the old behavior in other cases may be 'good enough'. I.e you will find in greclipse code base things may not always have 'correct' implementations. But if you can change an implementation to be 'more correct' (i.e. it does the right thing in strictly more cases than before) then it is a good change to make, even if it is not 'correct' because it doesn't fix all problems.

> but that doesn't seem to make any sense before the problems described above are not resolved.

Agreed... you should get to the bottom of why these other things/tests break. Some of it may be other defects you are uncovering, others may just be the tests 'expected behavior' should be changed because your new implementation is 'more correct' than what the test expects.

Comment by Mauro Molinari [ 02/Jul/14 ]

I have another similar case, which I think is related to this one. Suppose you depend on org.hibernate:hibernate-core:3.5.6-Final and that you have:

class F {
	static main(args) {
		SessionFactory sf = new SessionFactoryImpl(null, null, null, null, null)
		SQLQuery query = sf.currentSession.createSQLQuery('SELECT BLA BLA')
	}
}

This snippet is nonsense, but it serves the purpose. Here, the call to createSQLQuery(String) is confused by Greclipse with createSQLQuery(String, String, Class), which is deprecated, so the editor shows the deprecation decoration on my call.

This appears to be quite a severe problem and I'm starting to think that Greclipse can't handle method overloading at all. It it is so, it's surprising that this problem hasn't arisen before...

Comment by Vasiliy Kizhaev [ 07/Jul/14 ]

A PR for the original issue is submitted: https://github.com/groovy/groovy-eclipse/pull/59

As for your last comment, Mauro, this doesn't look like a similar issue and it won't be fixed by the solution I've created the PR for.
Anyway, I'm going to take a look at it, thanks a lot

Comment by Mauro Molinari [ 07/Jul/14 ]

Hi Vasiliy,
sorry for the fact I thought it was somewhat related to this. I've opened GRECLIPSE-1755 for it.

Comment by Vasiliy Kizhaev [ 07/Jul/14 ]

Hi Mauro,
That is great, thank you!

Comment by Vasiliy Kizhaev [ 08/Jul/14 ]

Pull request for the issue has been merged: https://github.com/groovy/groovy-eclipse/pull/56

Comment by Mauro Molinari [ 01/Sep/14 ]

I verified the main issue is fixed in 2.9.1.xx-201408202052-e44. Thank you!
However please note that I opened GRECLIPSE-1783 for a secondary small issue still present.





[GRECLIPSE-1701] Duplicated DSL scripts in Eclipse Package explorer Created: 07/Jan/14  Updated: 04/Jun/14  Resolved: 04/Jun/14

Status: Closed
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.9.0.Release
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mateusz Polnik Assignee: Unassigned
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse SDK: Version: 4.3.1, Build id: M20130911-1000
Groovy-Eclipse Plugin: 2.9.0.xx-20131127-1000-e43-RELEASE Groovy version: org.codehaus.groovy


Attachments: Zip Archive DuplicatedDslScriptsInEclipsePackageExplorer.zip    
Number of attachments : 1

 Description   

Scenario:
Please note that DSL configuration files have customary "jmon" extension.

1. Register jmon extension as a Groovy Source File content type in Eclipse settings.
Window -> Preferences -> General -> Content Types -> Text -> Java Source File -> Groovy Source File -> Add
[Screen 1]
2. Ignore temporary workspace problems and convert project to Groovy.
Project properties -> Configure -> Convert to Groovy project
[Screen 2]
3. Register jmon extension as Groovy script to exclude it from compilation.
Window -> Preferences -> Groovy -> Compiler -> Add
[Screen 3]
Remember to check newly added extension in the list and apply your changes.
[Screen 4]
4. Reset Eclipse
File -> Restart
5. DSL scipts are displayed two times in Eclise Package Explorer. They are no duplicates in file system.
[Screen 5]

Expected behaviour:
DSL scripts are displayed only once.



 Comments   
Comment by Vasiliy Kizhaev [ 15/May/14 ]

I performed all the steps with a random java project (I've created a file with "jmon" extension containing some Groovy script inside the project beforehand) but the bug was not reproduced.
Do I need any specific project and/or jmon files?

P.S. I use Windows so that can be an OS-specific issue.





[GRECLIPSE-1700] static modifier on inner class is removed by the compiler Created: 26/Dec/13  Updated: 11/Jun/14  Resolved: 04/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Blocker
Reporter: Mathieu Carbou Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
  • Maven 3.0.4
  • groovy-eclipse-compiler 2.8.0-01
  • groovy-eclipse-batch 2.1.8-01
  • groovy-all 2.2.1

Attachments: Zip Archive static-issue.zip    
Testcase included: yes
Number of attachments : 1

 Description   

Groovy class MClass.groovy

Unable to find source-code formatter for language: groovy. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
class MClass {
    static class InnerClass {}
}

pom.xml:

        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
                <configuration>
                    <compilerId>groovy-eclipse-compiler</compilerId>
                    <source>${jdk.version}</source>
                    <target>${jdk.version}</target>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-compiler</artifactId>
                        <version>2.8.0-01</version>
                    </dependency>
                    <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-batch</artifactId>
                        <version>2.1.8-01</version>
                    </dependency>
                </dependencies>
            </plugin>
            <plugin>
                <groupId>org.codehaus.groovy</groupId>
                <artifactId>groovy-eclipse-compiler</artifactId>
                <version>2.8.0-01</version>
                <extensions>true</extensions>
            </plugin>
        </plugins>

after mvn clean compile, it produces the following .class (extracted with JD-GUI)

import groovy.lang.GroovyObject;
import groovy.lang.MetaClass;
import org.codehaus.groovy.runtime.callsite.CallSite;

public class MClass
  implements GroovyObject
{
  public MClass()
  {
    MClass this;
    CallSite[] arrayOfCallSite = $getCallSiteArray();
    MetaClass localMetaClass = $getStaticMetaClass();
    this.metaClass = localMetaClass;
  }

  static
  {
    __$swapInit();
  }

  public class InnerClass
    implements GroovyObject
  {
    public InnerClass()
    {
      InnerClass this;
      CallSite[] arrayOfCallSite = $getCallSiteArray();
      MetaClass localMetaClass = $getStaticMetaClass();
      this.metaClass = localMetaClass;
    }

    static
    {
      __$swapInit();
    }
  }
}

See the zip file to reproduce the issue. The compiled file contains no static modifier.

It works with groovy-eclipse-batch 2.1.5-03 but not 2.1.8-01



 Comments   
Comment by Vasiliy Kizhaev [ 23/May/14 ]

The issue is still valid as I am able to reproduce it on 2.9.0.

Comment by Vasiliy Kizhaev [ 04/Jun/14 ]

A pull request for the fix was submitted: https://github.com/groovy/groovy-eclipse/pull/52

Comment by Andy Clement [ 10/Jun/14 ]

I've only been able to recreate this problem using the attached sample that was using the groovy 2.1.8 included with groovy-eclipse 2.8.0. If I look back at the history of the file AsmClassGenerator (where the code is produced and the attributes created for the class files) I see this precise problem with static was fixed in groovy 2.1.9. The fix was back ported into greclipse but a new gmaven snapshot for use in maven was not created. The exact changes can be seen in this diff (look at AsmClassGenerator):

git diff f1d46b3..0d2eb61

The solution is simply to move to a more recent groovy without the problem. I just tried with

<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.9.0-01-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.3.1-01-SNAPSHOT</version>
</dependency>

Vasily - do you agree?

Comment by Vasiliy Kizhaev [ 11/Jun/14 ]

Yes indeed. I don't know how I missed it, I really thought, that 2.1.8 is the latest version for groovy 2.1.
Sorry for that. I canceled the PR.





[GRECLIPSE-1698] Invalid content assist and accepted syntax for accessing properties with a non-lower case second letter Created: 18/Dec/13  Updated: 06/Mar/14  Resolved: 06/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Parser
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Critical
Reporter: Mauro Molinari Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following script:

class Foo {
	String getURL() {
		"hi"
	}
}

Foo foo = new Foo()
println foo.uRL

GRECLIPSE proposes foo.uRL to access the URL property and recognizes it as correct (no underline). However, if you run this script you'll get:

Caught: groovy.lang.MissingPropertyException: No such property: uRL for class: Foo
Possible solutions: URL

In fact, the one and only correct syntax to access the URL property is foo.URL, not foo.uRL. This is a special case for properties that do not have a lower case character as their second character.



 Comments   
Comment by Kris De Volder [ 06/Mar/14 ]

Alex contributed a pull request. Merged it.
https://github.com/groovy/groovy-eclipse/pull/12

Comment by Mauro Molinari [ 06/Mar/14 ]

Thanks guys!





[GRECLIPSE-1697] Assign to new local variable quick fix not working correctly inside a closure Created: 18/Dec/13  Updated: 06/Mar/14  Resolved: 06/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.8.0.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following code:

package a

class C
{
  int myMethod() {
		
	}
	
	void foo() {
		[1, 2].each {
			myMethod()| <= invoke quick fix here and select Assign to new local variable
		}
	}
}

Expected result: something like:

  [1, 2].each {
    def myMethod = myMethod()
  }

Actual result:

  def each = [1, 2].each {
    myMethod()
  }


 Comments   
Comment by Alex Boyko [ 06/Mar/14 ]

Seems to be resolved indirectly.





[GRECLIPSE-1696] Return generic type of a generic method not inferenced Created: 18/Dec/13  Updated: 01/Sep/14  Resolved: 23/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Denis Murashev
Resolution: Fixed  
Labels: help-requested, triaged, type-inference
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to GRECLIPSE-1129 Type parameters on methods are not re... Resolved
Number of attachments : 0

 Description   

Consider the following Java class:

package a;

public class A
{
	public <T> T myMethod(Class<T> claz)
	{
		return null;
	}
}

and the following Groovy class:

package a

class B {
	void foo() {
		A a = new A()
		def b = a.myMethod(String)
		b.trim()
	}
}

Type inference on b does not work. It should be detected as a String.



 Comments   
Comment by Denis Murashev [ 13/May/14 ]

It looks like some type inference problems are caused by using of reflection. So some type information is erased and is not available for type inference in IDE.
Debug shows that information about methods is loaded at org.codehaus.groovy.ast.ClassNode.lazyClassInit() method. Actually that method calls org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(CompileUnit, ClassNode), which uses reflection API inside it.

As a result, when code tries to get MethodNode from ClassNode the information about generics is lost.
So if there is statement like following:
def a = a.myMethod(String)
Then types of both sides of assignment are inferred as Object. Although actually it should be String.

Comment by blackdrag blackdrag [ 13/May/14 ]

generics like the ones in class A are available through reflection and are afaik added to the MethodNode as well as to the ClassNodes for return type and parameter types.

Comment by Denis Murashev [ 05/Jun/14 ]

Looks like problem is the same

Comment by Mauro Molinari [ 01/Sep/14 ]

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!





[GRECLIPSE-1695] sort{}.each{} and type inferencing Created: 18/Dec/13  Updated: 08/Apr/14  Resolved: 08/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.8.0.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following code:

List<String> myList = new ArrayList<String>()
myList.each {
  it.trim() // it detected as String correctly here
}
myList.sort { a, b ->
  a.trim() <=> b.trim() // a and b detected as String correctly here
}
myList.sort { a, b ->
  a.trim() <=> b.trim() // a and b detected as String correctly here
}.each {
  it.trim() // it not detected as String here!
}

In the last closure (sort{...}.each{...}) the type of the local variable it is not detected (i.e.: no code assist, unrecognized method underlined).



 Comments   
Comment by Alex Boyko [ 08/Apr/14 ]

Fixed for post 2.9.0. Most likely 2.9.1





[GRECLIPSE-1694] Trailing semicolon added by content assist when invoking a void method Created: 12/Dec/13  Updated: 20/May/14  Resolved: 19/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Minor
Reporter: Mauro Molinari Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following class:

package test

class G {

	private void oneMethod() {}
	
	private void anotherMethod() {
		oneMet|
	}
}

Invoke code assist at "|". The content assist completes with:

oneMethod();

By default in Groovy I would have expected:

oneMethod()


 Comments   
Comment by Vasiliy Kizhaev [ 19/May/14 ]

I cannot reproduce the issue on 2.9.0 version, so I assume the bug is fixed.

Comment by Mauro Molinari [ 20/May/14 ]

Hi Vasiliy, do you mean the latest state of 2.9.0? Because with 2.9.0.xx-201405030018-e43j8 I can still reproduce.

Thanks Vasiliy, I confirm it's fixed in 2.9.0.xx-201405030018-e43j8 already.

Comment by Vasiliy Kizhaev [ 20/May/14 ]

Hi Mauro, that's interesting, I'm using the same version and can't reproduce the bug.
I tried it on a fresh eclipse setup, so that can't be my settings. Which OS do you use? That could be an OS-specific issue.

Comment by Mauro Molinari [ 20/May/14 ]

Oh, well, you've been too fast! Sorry, I didn't notice Eclipse had pasted a Java snippet instead of a Groovy snippet. After re-creating the use case in the right way, I confirm it's fixed. Thank you and sorry for that!

Comment by Vasiliy Kizhaev [ 20/May/14 ]

Great! Thank you





[GRECLIPSE-1693] Save actions: "reorganize imports" removes the import of a type used only as generic Created: 06/Dec/13  Updated: 05/May/14  Resolved: 22/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.9.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Davide Cavestro Assignee: Denis Murashev
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GGTS Version: 3.4.0.RELEASE, Build Id: 201310051614
Groovy Eclipse Version: 2.9.0.xx-20130828-1400-e43-RELEASE


Attachments: Zip Archive import_issue.zip     PNG File missing_import.png     PNG File save_action_prefs.png    
Number of attachments : 3

 Description   

Enabling organize imports from save actions of Java Editor under certain circumstances some imports are automatically removed every time the user saves a file even if they are used. Even re-adding the import, at the first save it is removed.
I guess this happens where the imported type is only used as a generic type for the relevant class.

Follows a screenshot of the save actions preferences

and a screenshot of the editor error obtained at every save

If I simply add another reference to the removed type (i.e. within the javadoc) the everything works fine.

I've attached the relevant sources as import_issue.zip

UPDATE: even adding a reference to the removed type within the javadoc isn't enough to rokaround the issue.
Is there any way to disable Java Editor save actions only for groovy sources (but not Java ones)? This way I could workaround this issue (and some others for which I've not found yet the steps for systematic reproduction).



 Comments   
Comment by Alex Boyko [ 22/Apr/14 ]

@denis_murashev
Denis, the fix for this issue was good but the test was incorrect though You had to to put classes in different packages for the test case for the import statements to be generated I think. I did that and delivered the fix.
I didn't notice that the test isn't working because ran the test with JDK 8 which add Java FX on the class path. Thus, Bar is resolved to a Bar class from Java FX, import is added hence the test is passing. We need to run the Unit tests with JDK 7 because this is what the build machine is running them with.
Anyway, problem corrected and looks like we need to watch ourselves to run tests with Java 7 Otherwise, it was a good fix





[GRECLIPSE-1692] @Field annotation being removed by organize imports Created: 26/Nov/13  Updated: 11/Mar/14  Resolved: 11/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following source file:

import groovy.transform.Field;

@Field def x = 9

Perform organize imports and the import disappears.






[GRECLIPSE-1690] ClassNotFoundException on Kepler Created: 05/Nov/13  Updated: 05/Jun/14  Resolved: 05/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Pratyoosh Sharma Assignee: Unassigned
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Getting the same error on 2.8 & 2.9 Kepler Version: Kepler Service Release 1
Build id: 20130919-0819

Session data

eclipse.buildId=4.3.0.M20130911-1000
java.version=1.7.0
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product

Exception details
An error occurred while automatically activating bundle org.codehaus.groovy.eclipse.refactoring (987).

org.osgi.framework.BundleException: Exception in org.codehaus.groovy.eclipse.refactoring.Activator.start() of bundle org.codehaus.groovy.eclipse.refactoring.
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
	at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:478)
	at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
	at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:109)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at org.codehaus.groovy.eclipse.editor.GroovyAutoIndentStrategy.<init>(GroovyAutoIndentStrategy.java:50)
	at org.codehaus.groovy.eclipse.editor.GroovyConfiguration.getAutoEditStrategies(GroovyConfiguration.java:184)
	at org.eclipse.jface.text.source.SourceViewer.configure(SourceViewer.java:504)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.configure(JavaSourceViewer.java:230)
	at org.eclipse.ui.texteditor.AbstractTextEditor.createPartControl(AbstractTextEditor.java:3424)
	at org.eclipse.ui.texteditor.StatusTextEditor.createPartControl(StatusTextEditor.java:54)
	at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.createPartControl(AbstractDecoratedTextEditor.java:447)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.createPartControl(JavaEditor.java:3119)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.createPartControl(CompilationUnitEditor.java:1505)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.createPartControl(GroovyEditor.java:1016)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:142)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor.createPartControl(CompatibilityEditor.java:96)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:323)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:877)
	at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:857)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:119)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:333)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:254)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:102)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53)
	at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:129)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:949)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:633)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:735)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:706)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:700)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:685)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl$1.handleEvent(PartServiceImpl.java:90)
	at org.eclipse.e4.ui.services.internal.events.UIEventHandler$1.run(UIEventHandler.java:41)
	at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180)
	at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150)
	at org.eclipse.swt.widgets.Display.syncExec(Display.java:4688)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:205)
	at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:38)
	at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197)
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197)
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135)
	at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78)
	at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39)
	at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:80)
	at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:58)
	at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
	at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElement(ElementContainerImpl.java:171)
	at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.showElementInWindow(ModelServiceImpl.java:576)
	at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.bringToTop(ModelServiceImpl.java:543)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.delegateBringToTop(PartServiceImpl.java:610)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.bringToTop(PartServiceImpl.java:322)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:1034)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:3112)
	at org.eclipse.ui.internal.WorkbenchPage.access$21(WorkbenchPage.java:3034)
	at org.eclipse.ui.internal.WorkbenchPage$8.run(WorkbenchPage.java:3016)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:3012)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2976)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2967)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:534)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:493)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:360)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:167)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:268)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:233)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:275)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251)
	at org.eclipse.jdt.internal.ui.navigator.OpenAndExpand.run(OpenAndExpand.java:50)
	at org.eclipse.ui.actions.RetargetAction.run(RetargetAction.java:221)
	at org.eclipse.ui.navigator.CommonNavigatorManager$3.open(CommonNavigatorManager.java:185)
	at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:47)
	at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:866)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:864)
	at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1152)
	at org.eclipse.ui.navigator.CommonViewer.handleOpen(CommonViewer.java:462)
	at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1256)
	at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:275)
	at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:269)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:309)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
Caused by: java.lang.NoClassDefFoundError: org/codehaus/jdt/groovy/integration/LanguageSupport
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClassHoldingLock(ClasspathManager.java:638)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:613)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:574)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:492)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:465)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at org.codehaus.groovy.eclipse.refactoring.Activator.start(Activator.java:51)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
	... 130 more
Caused by: java.lang.ClassNotFoundException: org.codehaus.jdt.groovy.integration.LanguageSupport cannot be found by org.eclipse.jdt.groovy.core_2.9.0.xx-20131104-1200-e43-RELEASE
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	... 150 more
Root exception:
java.lang.NoClassDefFoundError: org/codehaus/jdt/groovy/integration/LanguageSupport
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClassHoldingLock(ClasspathManager.java:638)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:613)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:574)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:492)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:465)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at org.codehaus.groovy.eclipse.refactoring.Activator.start(Activator.java:51)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
	at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:478)
	at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
	at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:109)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at org.codehaus.groovy.eclipse.editor.GroovyAutoIndentStrategy.<init>(GroovyAutoIndentStrategy.java:50)
	at org.codehaus.groovy.eclipse.editor.GroovyConfiguration.getAutoEditStrategies(GroovyConfiguration.java:184)
	at org.eclipse.jface.text.source.SourceViewer.configure(SourceViewer.java:504)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.configure(JavaSourceViewer.java:230)
	at org.eclipse.ui.texteditor.AbstractTextEditor.createPartControl(AbstractTextEditor.java:3424)
	at org.eclipse.ui.texteditor.StatusTextEditor.createPartControl(StatusTextEditor.java:54)
	at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.createPartControl(AbstractDecoratedTextEditor.java:447)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.createPartControl(JavaEditor.java:3119)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.createPartControl(CompilationUnitEditor.java:1505)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.createPartControl(GroovyEditor.java:1016)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:142)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor.createPartControl(CompatibilityEditor.java:96)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:323)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:877)
	at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:857)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:119)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:333)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:254)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:102)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53)
	at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:129)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:949)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:633)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:735)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:706)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:700)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:685)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl$1.handleEvent(PartServiceImpl.java:90)
	at org.eclipse.e4.ui.services.internal.events.UIEventHandler$1.run(UIEventHandler.java:41)
	at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180)
	at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150)
	at org.eclipse.swt.widgets.Display.syncExec(Display.java:4688)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:205)
	at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:38)
	at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197)
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197)
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135)
	at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78)
	at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39)
	at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:80)
	at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:58)
	at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
	at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElement(ElementContainerImpl.java:171)
	at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.showElementInWindow(ModelServiceImpl.java:576)
	at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.bringToTop(ModelServiceImpl.java:543)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.delegateBringToTop(PartServiceImpl.java:610)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.bringToTop(PartServiceImpl.java:322)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:1034)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:3112)
	at org.eclipse.ui.internal.WorkbenchPage.access$21(WorkbenchPage.java:3034)
	at org.eclipse.ui.internal.WorkbenchPage$8.run(WorkbenchPage.java:3016)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:3012)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2976)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2967)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:534)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:493)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:360)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:167)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:268)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:233)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:275)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251)
	at org.eclipse.jdt.internal.ui.navigator.OpenAndExpand.run(OpenAndExpand.java:50)
	at org.eclipse.ui.actions.RetargetAction.run(RetargetAction.java:221)
	at org.eclipse.ui.navigator.CommonNavigatorManager$3.open(CommonNavigatorManager.java:185)
	at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:47)
	at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:866)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:864)
	at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1152)
	at org.eclipse.ui.navigator.CommonViewer.handleOpen(CommonViewer.java:462)
	at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1256)
	at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:275)
	at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:269)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:309)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
Caused by: java.lang.ClassNotFoundException: org.codehaus.jdt.groovy.integration.LanguageSupport cannot be found by org.eclipse.jdt.groovy.core_2.9.0.xx-20131104-1200-e43-RELEASE
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	... 150 more


 Comments   
Comment by Kris De Volder [ 05/Jun/14 ]

I haven't seen this kind of error using Greclipse on both Eclipse 4.3.2 and Eclipse 4.4 (RC2) so will close it for now as 'cannot reproduce'.

Feel free to reopen it and let me know if you still see this with the latest greclipse snapshot builds.





[GRECLIPSE-1689] ecilpse-4.4, luna, gives "An internal error occurred" Created: 01/Nov/13  Updated: 09/Apr/14  Resolved: 09/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rupert thurner Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

An internal error occurred during: "Initializing Java Tooling".
org/eclipse/osgi/framework/internal/core/FrameworkProperties



 Comments   
Comment by Alex Boyko [ 09/Apr/14 ]

Should be fixed in GGTS 3.5.1





[GRECLIPSE-1688] Call Hierarchy on Java method does not show usage in groovy class Created: 30/Oct/13  Updated: 20/May/14  Resolved: 20/May/14

Status: Closed
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Reported on Window 7 x64 but probably independent of OS


Number of attachments : 0

 Description   

Originally reported here: https://issuetracker.springsource.com/browse/STS-3596

I have this method in java:

public Store getStoreByNumber(String storeNumber)

and this call in groovy:

 def getSingleStore(def storeId){
        def store = storeDao.getStoreByNumber(storeId)
}

If I press Ctrl+Alt+h while highlighting getStoreByNumber in the java file I will not see the call to this method in the groovy file.



 Comments   
Comment by Vasiliy Kizhaev [ 20/May/14 ]

Seems to be fixed in 2.9.0.





[GRECLIPSE-1687] Error reporting broken in groovy-eclipse-compiler 2.8.0 Created: 28/Oct/13  Updated: 20/May/14  Resolved: 20/May/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Rustam Abdullaev Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive gtest2.zip    
Number of attachments : 1

 Description   

Error reporting seems to be broken in groovy-eclipse-compiler 2.8.0-01.
When there is 1 syntax error in the project, the error is not shown in Maven logs, only the fact that there is an error is shown.
With 2.7.0-01 the error is correctly logged to stderr.

Log with 2.8.0:

[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ groovy-eclipse-maven-tests ---
[INFO] Changes detected - recompiling the module!
[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Found 1 error and 0 warnings.
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.220s
[INFO] Finished at: Mon Oct 28 14:47:10 CET 2013
[INFO] Final Memory: 7M/16M
[INFO] ------------------------------------------------------------------------

Log with 2.7.0:

[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ groovy-eclipse-maven-tests ---
[INFO] Changes detected - recompiling the module!
[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
----------
1. ERROR in C:\Projects\gtest2\src\main\java\JavaClass.java (at line 4)
        private blah unused;
                ^^^^
blah cannot be resolved to a type
----------
1 problem (1 error)[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Found 1 error and 0 warnings.
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.329s
[INFO] Finished at: Mon Oct 28 14:48:14 CET 2013
[INFO] Final Memory: 6M/16M
[INFO] ------------------------------------------------------------------------

Attached test Maven project.



 Comments   
Comment by Michael Oryl [ 10/Jan/14 ]

Two people in my organization have seen this problem. Glad to know we can avoid it by miving back to 2.7.0. Thanks for that.

Comment by Vasiliy Kizhaev [ 20/May/14 ]

The issue seems to be fixed in 2.9.0-01-SNAPSHOT as I get the following output for this project:

[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ groovy-eclipse-maven-tests ---
[INFO] Changes detected - recompiling the module!
[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] C:\Users\Vasiliy_Kizhaev\Downloads\gtest2\gtest2\src\main\java\JavaClass.java:[4,-1] 
1. ERROR in C:\Users\Vasiliy_Kizhaev\Downloads\gtest2\gtest2\src\main\java\JavaClass.java (at line 4)
	private blah unused;
	        ^^^^
blah cannot be resolved to a type
----------
1 problem (1 error)

[ERROR] Found 1 error and 0 warnings.
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.564s
[INFO] Finished at: Tue May 20 18:47:09 MSK 2014
[INFO] Final Memory: 11M/155M
[INFO] ------------------------------------------------------------------------




[GRECLIPSE-1686] Annotations cannot be imported via quick fix tooltip Created: 18/Oct/13  Updated: 27/May/14  Resolved: 27/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Minor
Reporter: Keir Lawson Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Kepler 4.3.1 on Windows XP SP3


Number of attachments : 0

 Description   

Whilst using the groovy plugin I can import classes using the "quick fix" tooltip which appears when I hover over an unimported class within a source file, the same does not work for annotations.



 Comments   
Comment by Vasiliy Kizhaev [ 21/May/14 ]

The issue really takes place. For example, if you have the following code:

package test

@Target()
public @interface Test {

}

Target will be underlined and quick assist won't suggest you to import the annotation. However, if instead of Target you will type Targe and call auto-completion, the annotation will be imported automatically.

As Keir noticed, quick assist for common classes (not annotations) will suggest you to import the class in the first case.





[GRECLIPSE-1683] groovy-eclipse-compiler 2.8.0-01 incompatible with tycho 0.18.1 Created: 24/Sep/13  Updated: 22/May/14  Resolved: 22/May/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Fred Bricon Assignee: Unassigned
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
  • Create a groovy eclipse project from https://github.com/open-archetypes/groovy-eclipse-plugin-archetype
  • run 'mvn verify' -> Should build as expected
  • Change compiler plugin configuration to
    <plugin>
      <groupId>org.eclipse.tycho</groupId>
      <artifactId>tycho-compiler-plugin</artifactId>
      <version>${tycho.version}</version>
      <configuration>
          <compilerId>groovy-eclipse-compiler</compilerId>
      </configuration>
      <dependencies>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.8.0-01</version>
        </dependency>
        <dependency>
          <groupId>org.codehaus.groovy</groupId>
          <artifactId>groovy-eclipse-batch</artifactId>
          <version>2.1.5-03</version>
        </dependency>
      </dependencies>
    </plugin>
    
  • Execute 'mvn clean verify'
  • Project doesn't build :
    [WARNING] Error injecting: org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler
    java.lang.NoClassDefFoundError: org/codehaus/plexus/compiler/CompilerMessage
            at java.lang.Class.getDeclaredMethods0(Native Method)
            at java.lang.Class.privateGetDeclaredMethods(Class.java:2521)
            at java.lang.Class.getDeclaredMethods(Class.java:1845)
            at com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:674)
            at com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:366)
            at com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(ConstructorBindingImpl.java:165)
            at com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl.java:609)
            at com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:565)
            at com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:551)
            at com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:865)
            at com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
            at com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
            at com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
            at com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
            at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
            at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
            at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
            at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
            at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
            at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
            at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
            at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
            at org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
            at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
            at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
            at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
            at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
            at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
            at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
            at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
            at com.google.inject.Scopes$1$1.get(Scopes.java:59)
            at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
            at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
            at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
            at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
            at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
            at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
            at java.util.AbstractMap.get(AbstractMap.java:182)
            at org.codehaus.plexus.compiler.manager.DefaultCompilerManager.getCompiler(DefaultCompilerManager.java:54)
            at copied.org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:309)
            at org.eclipse.tycho.compiler.AbstractOsgiCompilerMojo.execute(AbstractOsgiCompilerMojo.java:239)
            at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
            at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
            at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
            at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
            at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
            at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
            at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
            at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
            at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
            at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
            at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
            at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
            at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.lang.reflect.Method.invoke(Method.java:606)
            at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
            at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
            at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
            at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
    Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.compiler.CompilerMessage
            at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
            at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
            at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
            at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
            ... 62 more
    [INFO] ------------------------------------------------------------------------
    [INFO] Reactor Summary:
    [INFO]
    [INFO] groopler :: parent ................................ SUCCESS [0.076s]
    [INFO] groopler :: core .................................. FAILURE [0.995s]
    [INFO] groopler :: test .................................. SKIPPED
    [INFO] groopler :: feature ............................... SKIPPED
    [INFO] groopler :: update site ........................... SKIPPED
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 18.799s
    [INFO] Finished at: Tue Sep 24 12:50:28 CEST 2013
    [INFO] Final Memory: 72M/661M
    [INFO] ------------------------------------------------------------------------
    [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.18.1:compile (default-compile) on project groopler.core: Execution default-compile of g
    oal org.eclipse.tycho:tycho-compiler-plugin:0.18.1:compile failed: A required class was missing while executing org.eclipse.tycho:tycho-compiler-plugin:0.18.1:c
    ompile: org/codehaus/plexus/compiler/CompilerMessage
    [ERROR] -----------------------------------------------------
    [ERROR] realm =    plugin>org.eclipse.tycho:tycho-compiler-plugin:0.18.1
    [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
    [ERROR] urls[0] = file:/D:/Dev/maven/repository/org/eclipse/tycho/tycho-compiler-plugin/0.18.1/tycho-compiler-plugin-0.18.1.jar
    [ERROR] urls[1] = file:/D:/Dev/maven/repository/org/codehaus/groovy/groovy-eclipse-compiler/2.8.0-01/groovy-eclipse-compiler-2.8.0-01.jar
    [ERROR] urls[2] = file:/D:/Dev/maven/repository/org/apache/maven/plugins/maven-compiler-plugin/3.0/maven-compiler-plugin-3.0.jar
    [ERROR] urls[3] = file:/D:/Dev/maven/repository/org/apache/maven/shared/maven-shared-utils/0.1/maven-shared-utils-0.1.jar
    [ERROR] urls[4] = file:/D:/Dev/maven/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
    [ERROR] urls[5] = file:/D:/Dev/maven/repository/org/apache/maven/shared/maven-shared-incremental/1.0/maven-shared-incremental-1.0.jar
    [ERROR] urls[6] = file:/D:/Dev/maven/repository/org/codehaus/plexus/plexus-compiler-javac/2.0/plexus-compiler-javac-2.0.jar
    [ERROR] urls[7] = file:/D:/Dev/maven/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
    [ERROR] urls[8] = file:/D:/Dev/maven/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
    [ERROR] urls[9] = file:/D:/Dev/maven/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
    [ERROR] urls[10] = file:/D:/Dev/maven/repository/org/codehaus/groovy/groovy-eclipse-batch/2.1.5-03/groovy-eclipse-batch-2.1.5-03.jar
    [ERROR] urls[11] = file:/D:/Dev/maven/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
    [ERROR] urls[12] = file:/D:/Dev/maven/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
    [ERROR] urls[13] = file:/D:/Dev/maven/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
    [ERROR] urls[14] = file:/D:/Dev/maven/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
    [ERROR] urls[15] = file:/D:/Dev/maven/repository/org/codehaus/plexus/plexus-utils/3.0.7/plexus-utils-3.0.7.jar
    [ERROR] urls[16] = file:/D:/Dev/maven/repository/org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar
    [ERROR] urls[17] = file:/D:/Dev/maven/repository/org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar
    [ERROR] urls[18] = file:/D:/Dev/maven/repository/org/codehaus/plexus/plexus-archiver/2.2/plexus-archiver-2.2.jar
    [ERROR] urls[19] = file:/D:/Dev/maven/repository/org/codehaus/plexus/plexus-io/2.0.5/plexus-io-2.0.5.jar
    [ERROR] urls[20] = file:/D:/Dev/maven/repository/org/eclipse/tycho/tycho-compiler-jdt/0.18.1/tycho-compiler-jdt-0.18.1.jar
    [ERROR] urls[21] = file:/D:/Dev/maven/repository/org/eclipse/tycho/org.eclipse.jdt.core/3.9.0.v20130604-1421/org.eclipse.jdt.core-3.9.0.v20130604-1421.jar
    [ERROR] urls[22] = file:/D:/Dev/maven/repository/org/eclipse/tycho/org.eclipse.jdt.compiler.apt/1.0.600.v20130530-1010/org.eclipse.jdt.compiler.apt-1.0.600.v201
    30530-1010.jar
    [ERROR] Number of foreign imports: 1
    [ERROR] import: Entry[import  from realm ClassRealm[project>foo.bar.myplugin:groopler:1.0.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
    [ERROR]
    [ERROR] -----------------------------------------------------: org.codehaus.plexus.compiler.CompilerMessage
    [ERROR] -> [Help 1]
    [ERROR]
    [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR]
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
    [ERROR]
    [ERROR] After correcting the problems, you can resume the build with the command
    [ERROR]   mvn <goals> -rf :groopler.core
    


 Comments   
Comment by Vasiliy Kizhaev [ 22/May/14 ]

Performed this steps and did not get any errors. Tried both tycho-compiler-plugin:0.18.1 and tycho-compiler-plugin:0.20.0.





[GRECLIPSE-1682] Slashy string with dollar signs breaks syntax highlighting Created: 23/Sep/13  Updated: 10/Jun/14  Resolved: 10/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: GubeSpam Assignee: Denis Murashev
Resolution: Fixed  
Labels: help-requested, triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, STS 3.3.0.RELEASE


Attachments: JPEG File screenshot-1.jpg    
Number of attachments : 1

 Description   

If enter the following into a Groovy editor, everything between teh first and second dollar signs ($) is highlighted in blue.

testConvertParamPrefix = [
    'input_file' : /input_file$/
]

def devServerName = "a"

cmConnectInfoSupplier = [info:[hostUrl:"http://$devServerName:8080/anything/"]]
        
another = line

I see GRECLIPSE-124 but it is unclear to me whether that bug is the same or separate from this, as I'm uncertain how the versioning between STS and GREclipse works.



 Comments   
Comment by Vasiliy Kizhaev [ 22/May/14 ]

The issue is valid, I created a test case for it: https://github.com/groovy/groovy-eclipse/pull/47





[GRECLIPSE-1679] Annotations created with AnnotationCollector unusable outside of current project Created: 13/Sep/13  Updated: 08/May/14  Resolved: 08/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.8.0.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jon Barksdale Assignee: Kris De Volder
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive compile-static-annotations.tar.gz    
Testcase included: yes
Number of attachments : 1

 Description   

If I create an annotation using AnnotationCollector, I can use it in the same code base, but it is unusable from a jar. Originally I thought it was related to CompileStatic, but it just seems to affect annotations with AnnotationCollector.

Test case is attached. It uses a multimodule project to demonstrate the error. The annotation is created in the annotation module, and used in the usage module, where it explodes at compile time.

I also included a gradle build, with the same basic setup, and it does not explode, implying the maven groovy-eclipse-compiler plugin.



 Comments   
Comment by Kris De Volder [ 08/May/14 ]

Closing as duplicate of GRECLIPSE-1719





[GRECLIPSE-1676] Cannot create Groovy class with Eclipse Kepler Created: 20/Aug/13  Updated: 22/May/14  Resolved: 22/May/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Alex Netkachov Assignee: Unassigned
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Kepler (4.3) x64, JDK 1.6


Attachments: Text File configuration.txt     Text File errors.txt    
Number of attachments : 2

 Description   

While creating the Groovy Class in Eclipse Kepler I've got the following error:

'Building workspace' has encountered a problem.
Errors occurred during the build.
Errors running builder 'Java Builder' on project 'Test'.
org/codehaus/jdt/groovy/integration/LanguageSupportFactory

Creation of element failed.
org.eclipse.jdt.internal.core.CompilationUnit cannot be cast to org.codehaus.jdt.groovy.model.GroovyCompilationUnit

Steps to reproduce:

  1. Download Eclipse Kepler for Java Development and unpack it to C:\Projects\Groovy\eclipse.
  2. Install EGroovy as described on the page http://groovy.codehaus.org/Eclipse+Plugin
  3. Create Groovy project with default settings.
  4. New -> Groovy Class -> specify class name and click Finish.
  5. Error appears.

Actually, the command creates the empty class, but it cannot be edited - doubleclicking on the class opens editor but it looks like it is in some kind of readonly mode.

Eclipse configuration details and error log files are attached.



 Comments   
Comment by Vasiliy Kizhaev [ 22/May/14 ]

Tried to reproduce on Win7, everything seems to work fine.





[GRECLIPSE-1675] Compiler customizer support Created: 19/Aug/13  Updated: 19/Aug/13  Resolved: 19/Aug/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We need to support the ability to supply a compiler customizer.



 Comments   
Comment by Andy Clement [ 19/Aug/13 ]

Committed support for this. The property to specify in the .settings/org.eclipse.jdt.core.prefs for the project is:

org.eclipse.jdt.core.compiler.groovy.groovyCustomizerClassesList=com.foo.Bar

Multiple customizers can be specified using commas to separate the names.





[GRECLIPSE-1673] java.lang.ArrayIndexOutOfBoundsException: 5098 at org.codehaus.groovy.eclipse.codeassist.CharArraySourceBuffer.charAt() Created: 16/Aug/13  Updated: 22/May/14  Resolved: 22/May/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: David Tonhofer Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Fedora 18; Eclipse Juno


Attachments: Text File Raw Source.txt     Text File StackTraces.txt    
Number of attachments : 2

 Description   

Editing source results in a popup about a Content Assist error. A stacktrace could be found in the eclipse log (attached)

I also noticed that the eclipse log has a NullPointerException a bit earlier; it is also in the attachment.

Furthermore attached raw code causing trouble.



 Comments   
Comment by Vasiliy Kizhaev [ 22/May/14 ]

I am able to reproduce the issue on 2.8.0, but I can't catch any errors using 2.9.0, so I assume the issue was fixed.





[GRECLIPSE-1672] NullPointerException in org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35) Created: 13/Aug/13  Updated: 16/Jun/14  Resolved: 16/Jun/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: David Tonhofer Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Fedora 18


Attachments: Text File exception.txt     File MaisonsEtLogementsAuLuxembourg.groovy    
Number of attachments : 2

 Description   

Version: Juno Service Release 2
Build id: 20130225-0426

Source file (still being edited, thus not in principle compilable) attached.

Exception attached.



 Comments   
Comment by David Tonhofer [ 16/Aug/13 ]

Encountered another one. This one happened when putting "@Immutable" onto a static inner class.

java.lang.NullPointerException
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitIfElse(CodeVisitorSupport.java:64)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitIfElse(ClassCodeVisitorSupport.java:219)
at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:41)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructor(ClassCodeVisitorSupport.java:120)
at org.codehaus.groovy.transform.ImmutableASTTransformation.doAddConstructor(ImmutableASTTransformation.java:167)
at org.codehaus.groovy.transform.ImmutableASTTransformation.createConstructorMapCommon(ImmutableASTTransformation.java:269)
at org.codehaus.groovy.transform.ImmutableASTTransformation.createConstructorMap(ImmutableASTTransformation.java:254)
at org.codehaus.groovy.transform.ImmutableASTTransformation.createConstructors(ImmutableASTTransformation.java:206)
at org.codehaus.groovy.transform.ImmutableASTTransformation.visit(ImmutableASTTransformation.java:132)
at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.analyseCode(GroovyCompilationUnitDeclaration.java:2098)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1230)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:712)
at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1181)
at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:807)
at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:544)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:537)
at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:480)
at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170)
at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

Comment by Vasiliy Kizhaev [ 16/Jun/14 ]

I cannot reproduce the first issue, so it might got fixed.
Speaking about the second one, I can't get this very exception, but calling auto-completion on any annotation cause another exception, that is not related to groovy-eclipse since it can be reproduced in plain eclipse.





[GRECLIPSE-1671] greclipse and egit block files when used together Created: 10/Aug/13  Updated: 16/Jun/14  Resolved: 16/Jun/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rupert thurner Assignee: Unassigned
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Number of attachments : 0

 Description   

include a checked in jar in the classpath, which is not there in another branch. then switching the branch with egit is not possible any more as one of egit and greclipse is blocking this.

see the discussion on the egit bugtracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=414158 .

the resume seems that greclpise is guilty as it locks the files, and i was just lucky that i only saw it with both, egit and greclpise. the bug on the eclipse bug tracker includes an example project as well.



 Comments   
Comment by Andy Clement [ 19/Aug/13 ]

Might want to look at:

http://groovy.codehaus.org/Groovy-Eclipse+2.1.2+New+and+Noteworthy#Groovy-Eclipse212NewandNoteworthy-Optionalnon-jarlockingbehaviouronWindows

which gives you a system property you can set to lessen the locking (comes with a likely performance hit, hence it being opt-in)

Comment by rupert thurner [ 14/Sep/13 ]

fyi, windows should allow to open files with the flag FILE_SHARE_DELETE, which then allows the file to be deleted even when the handle is open:

this then comes without a performance hit.





[GRECLIPSE-1669] Better @Grab handling Created: 02/Aug/13  Updated: 19/Aug/13  Resolved: 02/Aug/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When Grab goes wrong the errors are hideous, let's improve things.



 Comments   
Comment by Andy Clement [ 02/Aug/13 ]

Sample code, note the AspectJ version is wrong and includes a extraneous 'x'


@Grab(group="joda-time", module="joda-time", version="1.6")
@Grab(group="org.aspectj", module="aspectjweaver", version="1.6.11x")
class C {
	def printDate() {
	      def dt = new org.joda.time.DateTime()
		  def world = new org.aspectj.weaver.bcel.BcelWorld();
		  print dt;
	}
	public static void main(String[] argv) {
		new C().printDate()
	}
}

When run with 'groovy' or in the IDE it produces a nasty exception that ends up recorded against the first line of the source file:

General error during conversion: Error grabbing Grapes -- [unresolved dependency: org.aspectj#aspectjweaver;1.6.11x: not found]

java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: org.aspectj#aspectjweaver;1.6.11x: not found]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
... lots of other crap cut out ...

By enhancing GrabAnnotationTransformation we can get to something smarter.

Comment by Andy Clement [ 02/Aug/13 ]

Modified GrabAnnotationTransformer and now we get:

Groovy:unable to resolve class org.aspectj.weaver.bcel.BcelWorld 	line 7	
Groovy:Error grabbing Grapes -- [unresolved dependency: org.aspectj#aspectjweaver;1.6.11x: not found]	line 3	
Comment by Andy Clement [ 19/Aug/13 ]

Further change. It appears if you have multiple classes in a source file, the grabs end up duplicated in the 'grabmap' that is passed to Ivy. This will work but is unnecessary, I changed from a List to a Set which avoids the dups.





[GRECLIPSE-1668] Eclipse freezes during mark occurrences in groovy editor Created: 25/Jul/13  Updated: 26/May/14  Resolved: 26/May/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: GubeSpam Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, 64 bit, Groovy/Grails Tool Suite 3.3.0 (Eclipse Juno 4.2)


Attachments: Text File mark_ocurrence_main_thread_trace.txt     Text File mark_ocurrence_worker_threads_trace.txt    
Number of attachments : 2

 Description   

If another window (other than Eclipse) is selected, then I click on Eclipse, specifically on an occurrence of a local variable within a groovy editor, Eclipse freezes up and I notice high CPU utilitzation for about 30 seconds. It seems to have something to do with the mark occurrences functionality. Every time a do a thread dump while Eclipse is frozen, I pretty much always get a stack trace like the one attached (with thread "main"), with the top of the stack being in java.io.WinNTFileSystem.getLastModifiedTime.

Secondly, if Eclipse and the groovy editor is already active and has focus, and I click an occurrence of a local variable, Eclipse does not freeze up, but also the marked occurrences are not updated, and the CPU usage goes up, as in the other case described above. If I keep clicking around in the editor on different variables, the occurrences are still not updated, but when I look at the live threads in VisualVM, I notice that more and more worker threads keep getting created, all but one of which are in a BLOCKED state; the one which is not has a stack trace similar to the "main" thread example (see attachment).

A few thoughts

  • Something seems to be making the getLastModifiedTime call slow, but I'm not even sure why that's needed here
  • I would think that only a single working thread should be working on the mark ocurrences feature; a new thread shouldn't be created each time the cursor is moved to a new variable

I previously filed this bug with Eclipse, but was told I should file it here instead. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=413681



 Comments   
Comment by GubeSpam [ 25/Jul/13 ]

After a few searches on the web, it looks like java.io.WinNTFileSystem.getLastModifiedTime seems to be involved in a number of performance issues in various java-based products, including ColdFusion and JBoss. One page I saw specifically stated that this system call is not very performant.

Perhaps there could be a way of caching information at some level, so that the code path involving WinNTFileSystem.getLastModifiedTime is taken less often?

Someone created a "patch" for ColdFusion, using AspectJ: http://forums.adobe.com/thread/1048647

Comment by Vasiliy Kizhaev [ 26/May/14 ]

Tried to reproduce the issue on 2.9.0, but everything seems to work fine, even VisualVM didn't show any sign of unwanted behavior hence I assume the bug is fixed.





[GRECLIPSE-1667] eclipse groovy plugin + scala plugin co-existence? Created: 20/Jul/13  Updated: 26/May/14  Resolved: 26/May/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Andrei Pozolotin Assignee: Unassigned
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

according to Peter Niederwieser, it is impossible

to have both scala and groovy in the same project:

http://forums.gradle.org/gradle/topics/how_to_setup_project_to_support_different_languages_java_clojure_groovy_scala_etc

I am curious if there is a work around for this issue?



 Comments   
Comment by Andrew Eisenberg [ 21/Jul/13 ]

Unfortunately, this feature is not available since the groovy and scala builders may not both be applied to the same project. My recommendation is to separate the different languages into their own projects.





[GRECLIPSE-1666] Internal compiler error on groovy class at first character (sometimes) Created: 19/Jul/13  Updated: 16/Jun/14  Resolved: 16/Jun/14

Status: Closed
Project: GRECLIPSE
Component/s: Compiler Integration, Maven integration
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Arne Burmeister Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux amd64 2.6.18-164.6.1.0.1.el5, JDK 1.7.0_09


Number of attachments : 0

 Description   

During some builds the compiler creates an internal error on the first character of a groovy source file (before "package"). Just rebuilding typically helps. The groovy source file does not change, during builds the affected file differs (we have a multi-module project with more than 1000 groovy files).

The Error logs as follows:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project efi-svc-srating-fea-ep2-baufismart: Compilation failure: Compilation failure:
[ERROR] /.../src/main/java/de/.../MyGroovyClass.java: 1. ERROR in /.../src/main/java/.../MyGroovyClass.java (at line 0)
[09:53:10][ERROR] package de.my...;
[09:53:10][ERROR] ^
[09:53:10][ERROR] Internal compiler error: java.lang.IllegalStateException: Import reference alongside class de.my...MyGroovyClass will trigger later failure: java.lang.Boolean.TRUE declSourceStart=8077 declEnd=999 at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.createImports(GroovyCompilationUnitDeclaration.java:362)

The maven integration is:

      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.7</source>
          <maxmem>512m</maxmem>
          <target>1.7</target>
          <encoding>UTF-8</encoding>
          <compilerId>groovy-eclipse-compiler</compilerId>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.8.0-01</version>
          </dependency>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-batch</artifactId>
            <version>1.8.6-01</version>
          </dependency>
        </dependencies>
      </plugin>


 Comments   
Comment by Arne Burmeister [ 19/Jul/13 ]

Additional information: we use maven 3.0.4 with option -T 1C

Comment by Arne Burmeister [ 21/Aug/13 ]

I think we found circumstances to reproduce the bug! All problamatic groovy files seem to include a static import to Boolean with a full qualified package:

import static java.lang.Boolean.TRUE

When modified to

import static Boolean.TRUE

the error does no longer occur!

Comment by David Tonhofer [ 16/Oct/13 ]

I am seeing a similar error

Internal compiler error: java.lang.IllegalStateException: Import reference alongside class FOO will trigger later failure: declSourceStart=X declEnd=Y

after Eclipse restart.

I think the compiler says that there is something fishy about the code at character position X...X+Y, clearly in the imports.

If you are too lazy to count characters by hand, you can do the following on Unix:

DUMP=`cat foo_source_file.groovy`
let Z=$X+$Y
echo $DUMP | cut --characters=$X-$Z

It turns out that imports from java.util cause an allergy (note that the ; have not been removed by the formatter for some reason):

import java.util.Date;
import java.util.List;
import java.util.Map;
import java.util.TimeZone;

Removing the above helps. After all, the corresponding package is imported automatically anyway:

http://stackoverflow.com/questions/4912400/what-packages-does-1-java-and-2-groovy-automatically-import

Comment by David Tonhofer [ 16/Oct/13 ]

Just an addendum: The addition of imports of e.g. "java.util.List" occurs when one copy-pastes pieces of code between Groovy compilation units. The additional imports are then added in front of the package declaration, leading to an immediate error:

import java.util.List;

package ng.admin.subdiv.maps

import ng.admin.naming.Naming.DistanceRatioInfo
import ng.admin.subdiv.units.Canton

I then usually move the package declaration up, but will now just deleted the added lines.

This has been the case for some time, so is not linked to the latest version of GRECLIPSE, but I used to ignore this annoyance.

Comment by Vasiliy Kizhaev [ 16/Jun/14 ]

I cannot reproduce this anymore so I assume the bug is fixed.





[GRECLIPSE-1665] Trailing dollar sign in regexps breaks formatting of the rest of the file Created: 19/Jul/13  Updated: 19/Jul/13  Resolved: 19/Jul/13

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.7.2.Release, 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Jörg Thönnes Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version: 2.8.0.xx-20130619-0900-e42
Groovy version: org.codehaus.groovy
Eclipse 3.8.2 Juno


Attachments: PNG File clipboard.png     PNG File clipboard.png    
Number of attachments : 2

 Description   

A trailing dollar sign in Groovy regexps causes the formatting to fail.
E.g.

/(?<=\.log).*/

works, while

/(?<=\.log).*$/

breaks the formatting of the rest. See attached screen shots.

This is reported against a snapshot version of GRECLIPSE, see environment details above.



 Comments   
Comment by Jörg Thönnes [ 19/Jul/13 ]

Attached example of good formatting (without dollar sign).

Comment by Jörg Thönnes [ 19/Jul/13 ]

Attached example of broken formatting (with dollar sign appended).

Comment by Andrew Eisenberg [ 19/Jul/13 ]

This problem is due to Groovy's slashy string syntax. To disable, go to Preferences -> Groovy -> Editor and uncheck "Highlight $ slashy strings".

Comment by Jörg Thönnes [ 19/Jul/13 ]

OK, so this means that Eclipse formatting cannot be configured to take care of this special case?

Comment by Andrew Eisenberg [ 19/Jul/13 ]

No. Highlighting of strings is done through regex. Even though it does not do eager matching the regex will be matched only when there is a $/ and a /$ in a matching pair in regex literals (or even comments).

I could switch to using semantic highlighting for this (ie- use the parse tree to highlight strings), but this means that every time the AST breaks, you'd lose your highlighting.

I am considering just disabling slashy highlighting by default.

Comment by Jörg Thönnes [ 19/Jul/13 ]

Thanks for the explanation.





[GRECLIPSE-1664] DSL proposal appear first when there are other obvious completions Created: 18/Jul/13  Updated: 16/Jun/14  Resolved: 16/Jun/14

Status: Closed
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Pascal Rapicault Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive sampleArtifactoryUserPlugin.zip    
Number of attachments : 1

 Description   

In the following sample, when I ask for completion where the | symbol is found, the first choices that are proposed to me are global values coming from a DSL descriptor that I use in my project.
I'm a bit surprised by these proposals since I would normally expect to see the methods of the RepoPath class.

import org.artifactory.repo.RepoPath;
import org.artifactory.repo.RepoPathFactory;

executions {
foo()

{ def RepoPath p = RepoPathFactory.create("foo"); p.| }

}



 Comments   
Comment by Pascal Rapicault [ 18/Jul/13 ]

I'm using the 2.8.0.xx-20130703-1600-e43-RELEASE on top of Kepler

Comment by Andrew Eisenberg [ 19/Jul/13 ]

Groovy-Eclipse prioritizes DSL proposals over others. Is the problem that the DSL proposals are appearing where they shouldn't or is it just the ordering that is surprising?

Comment by Pascal Rapicault [ 19/Jul/13 ]

In this particular case I would expect the completion specific to the type to show up first. Having a whole bunch of useless proposal diminishes the value of the completion.

I also have the impression that DSL proposals are always showing up, though I would have to do more testing to confirm.

Comment by Andrew Eisenberg [ 19/Jul/13 ]

Well, if the dsl proposals are not appropriate at the point where you are getting them, then I'd think that the DSLD still needs some work. If you send it over to me, I can take a look and see what kind of improvements are possible.

Comment by Pascal Rapicault [ 23/Jul/13 ]

Attached is an Eclipse project setup with Maven, the dsld, and small groovy file.
The dsld file being used is from Artifactory.

Comment by Vasiliy Kizhaev [ 16/Jun/14 ]

Seems to be fixed in 2.9.0.





[GRECLIPSE-1663] Proper syntax highlighting extender rules Created: 10/Jul/13  Updated: 12/Jul/13  Resolved: 12/Jul/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This issue is set up to track the following github pull request:

https://github.com/groovy/groovy-eclipse/pull/7



 Comments   
Comment by Andrew Eisenberg [ 12/Jul/13 ]

Merged.





[GRECLIPSE-1662] Restore "monospace font" for Junit view while waiting for JDT patch Created: 09/Jul/13  Updated: 05/Jun/14  Resolved: 05/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Maxime HAMM Assignee: Unassigned
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Please, this feature is usefull for Spok users !... even if we need to uncheck and recheck it to switch to monospace font... can you please put it back while waiting for the JDT patch ?



 Comments   
Comment by Maxime HAMM [ 10/Jul/13 ]

Hi

In fact i'm working on a Spock plugin... and I've manage to change the font !

For the moment i did it in a somewhat "unusual manner".. but that's a workaround... while waiting for this eclipse request :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=411794

Comment by Andrew Eisenberg [ 10/Jul/13 ]

What is the workaround?

Comment by Maxime HAMM [ 11/Jul/13 ]

Hi Andrew
As we were discussing by email, I prepare a Spock plugin, very simple, for syntax coloring and completion on Spock keyword? then I added a non-usual peace of code to manage the Junit trace pane font : my plugin acts as a compilation participant (is the project has the "spock" nature) and is updating the font if necessary !
That's for sur not suitable for greclipse, but sounds reasonable for a Spock-specific plugin? while waiting for the eclipse request you made?
What's your Opinion Andrew ?
Maxime

Comment by Kris De Volder [ 05/Jun/14 ]

It looks like referenced Eclipse bug is fixed.
So I don't think anything Greclipse needs to fix anymore.

Correct me if I'm wrong, we can reopen the issue.





[GRECLIPSE-1661] groovy-eclipse-compiler Project Lombok integration not working anymore Created: 08/Jul/13  Updated: 06/Nov/13  Resolved: 09/Jul/13

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Pascal Schumacher Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apache Maven 3.0.5
Java version: 1.7.0_21, vendor: Oracle Corporation


Attachments: Zip Archive LombokTest.zip    
Testcase included: yes
Number of attachments : 1

 Description   

After upgrading the "groovy-eclipse-compiler" from version "2.7.0-01" to version "2.8.0-01" the project lombok integration stopped working:

D:\development\eclipse-projects\LombokTest>mvn clean test -e
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building LombokTest 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] — maven-clean-plugin:2.4.1:clean (default-clean) @ LombokTest —
[INFO] Deleting D:\development\eclipse-projects\LombokTest\target
[INFO]
[INFO] — maven-resources-plugin:2.5:resources (default-resources) @ LombokTest —
[debug] execute contextualize
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory D:\development\eclipse-projects\LombokTest\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ LombokTest —
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent!
[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
[INFO] Classpath: D:\development\eclipse-projects\LombokTest\target\classes;C:\Dokumente und Einstellungen\Pascal Schumacher\.m2\r
epository\org\codehaus\groovy\groovy-all\2.1.5\groovy-all-2.1.5.jar;C:\Dokumente und Einstellungen\Pascal Schumacher\.m2\repositor
y\org\projectlombok\lombok\0.11.8\lombok-0.11.8.jar;C:\Dokumente und Einstellungen\Pascal Schumacher\.m2\repository\junit\junit\4.
8.1\junit-4.8.1.jar;
[INFO] All args: [-cp, D:\development\eclipse-projects\LombokTest\target\classes;C:\Dokumente und Einstellungen\Pascal Schumacher\
.m2\repository\org\codehaus\groovy\groovy-all\2.1.5\groovy-all-2.1.5.jar;C:\Dokumente und Einstellungen\Pascal Schumacher\.m2\repo
sitory\org\projectlombok\lombok\0.11.8\lombok-0.11.8.jar;C:\Dokumente und Einstellungen\Pascal Schumacher\.m2\repository\junit\jun
it\4.8.1\junit-4.8.1.jar;, -d, D:\development\eclipse-projects\LombokTest\target\classes, -g, -s, D:\development\eclipse-projects\
LombokTest\target\generated-sources\annotations, -source, 1.5, -target, 1.5, -nowarn, -verbose, D:\development\eclipse-projects\Lo
mbokTest\src\main\java\test\DataTest.java]
[INFO] Found location <C:\Dokumente und Einstellungen\Pascal Schumacher\.m2\repository\org\codehaus\groovy\groovy-eclipse-batch\2.
1.5-03\groovy-eclipse-batch-2.1.5-03.jar> for className <org.eclipse.jdt.internal.compiler.batch.Main>
[INFO] Found location <C:\Dokumente und Einstellungen\Pascal Schumacher\.m2\repository\org\projectlombok\lombok\0.11.8\lombok-0.11
.8.jar> for className <lombok.core.Agent>
[INFO] Compiling in a forked process using C:\Dokumente und Einstellungen\Pascal Schumacher\.m2\repository\org\codehaus\groovy\gro
ovy-eclipse-batch\2.1.5-03\groovy-eclipse-batch-2.1.5-03.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.640s
[INFO] Finished at: Tue Jul 09 00:26:43 CEST 2013
[INFO] Final Memory: 5M/15M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project LombokTest:
Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:
compile (default-compile) on project LombokTest: Compilation failure
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:862)
at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

See attached example project.



 Comments   
Comment by Andrew Eisenberg [ 08/Jul/13 ]

Thanks for the bug report. Our integration tests are testing lombock with no problem. Maybe there's something different about your project. Will try it out.

Comment by Andrew Eisenberg [ 08/Jul/13 ]

Can you try the latest 2.9.0-01-SNAPSHOT? I just pushed out a fix that is making your project compile for me.

Comment by Pascal Schumacher [ 09/Jul/13 ]

With 2.9.0-01-SNAPSHOT the build works again. Thanks for the super quick fix.

Comment by Andrew Eisenberg [ 09/Jul/13 ]

Thanks for the feedback. Resolving.

Comment by Sean Flanigan [ 12/Sep/13 ]

Could you please put out some sort of release with this fix? A 2.8 backport, even a 2.9 alpha release, anything! 2.9.0-01 is quite a way off.

Comment by Antony Stubbs [ 16/Sep/13 ]

What was the problem?

Comment by Sean Flanigan [ 16/Sep/13 ]

Just the "Compilation failure" stacktrace shown in the bug report, when Lombok is added to the mix. The details of the compilation failure are not logged.

Comment by Antony Stubbs [ 16/Sep/13 ]

Right, but the reporter didn't specify that the upgrade enabled him to see what the root cause was, so he could fix it, he just said it worked after upgrading to the snapshot.

We were seeing the same stacktrace sort of thing, upgraded to the snapshot and everything "just worked".

Or are you saying, there was a problem (not the problem that the problem wasn't properly reported), and that the upgrade fixed the underlying problem?

If so, is there a reason that the compilation failures aren't logged properly?

Comment by Sean Flanigan [ 16/Sep/13 ]

Um, Antony, I don't think I'm following you. The SNAPSHOT fixes the problem for me too, whatever the cause. I'm just hoping there is a non-SNAPSHOT release soon.

Oh, I get it: you were asking Andrew about the problem in the code. I thought you were asking me for more details from an end-user point of view.

But yes, better logging for compilation errors would certainly have saved some time.

It looks like this was the fix (one line): https://github.com/groovy/groovy-eclipse/commit/92b8f13bcc7be18491fb389122f896851f0b2970





[GRECLIPSE-1660] Add new editor templates for junit tests Created: 08/Jul/13  Updated: 08/Jul/13  Resolved: 08/Jul/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This issue is setup to track the following pull request: https://github.com/groovy/groovy-eclipse/pull/5



 Comments   
Comment by Andrew Eisenberg [ 08/Jul/13 ]

Pull request has been merged.





[GRECLIPSE-1659] Allow Groovy Plugin to ignore duplicate options Created: 08/Jul/13  Updated: 10/Jul/13  Resolved: 10/Jul/13

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Karel Piwko Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

While configuring Groovy compiler via Maven Compiler plugin, I need a way how to allow passing multiple arguments with the same value, simply picking the latest value:

Suppose following pom.xml (effective pom), configuration comes from parent where I have no control:

<plugin>
                <!-- Compiler plugin enforces Java 1.6 compatibility and activates annotation processors -->
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <!-- here is the problem -->
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
                <executions>
                    <execution>
                        <id>default-testCompile</id>
                        <phase>test-compile</phase>
                        <goals>
                            <goal>testCompile</goal>
                        </goals>
                        <configuration>
                            <compilerId>groovy-eclipse-compiler</compilerId>
                            <showDeprecation>true</showDeprecation>
                            <showWarnings>true</showWarnings>
                            <compilerArguments>
                              <!-- here is the problem -->
                              <source>1.6</source>
                            </compilerArguments>
                        </configuration>
                    </execution>
                </executions>
                <dependencies>
                    <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-compiler</artifactId>
                        <version>2.7.0-01</version>
                    </dependency>
                </dependencies>
            </plugin>

The problem is, it simply works with java compiler, while when switching to groovy, it chokes on:

duplicate source compliance setting specification: -target
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Found 0 errors and 0 warnings.
[INFO] 1 error

In order to overcome that, there can be either:

1/ Removing duplicity checks for groovyc compiler
2/ groovyc arg to optionally ignore the checks
3/ Deduplication applied in groovy-maven-compiler

Let me know what you'd find the best, I can help with PR on GitHub.

You can reproduce behavior by running:

git clone https://github.com/kpiwko/aerogear-unified-push-server
git checkout merged-tests
mvn clean verify



 Comments   
Comment by Andrew Eisenberg [ 08/Jul/13 ]

I'm able to reproduce the problem with your repo. It looks like the jdt compiler is stricter about having duplicate options than javac is. So, the behavior of JDT is to throw an exception in this case, but not so in javac.

I won't have time to work on this in the next few days, but if you are interested in submitting a pull request, I would accept it. This link points to where the custom command line arguments are generated:
https://github.com/groovy/groovy-eclipse/blob/master/extras/groovy-eclipse-compiler/src/main/java/org/codehaus/groovy/eclipse/compiler/GroovyEclipseCompiler.java#L310

For each custom compiler arg, you will need to see if that arg already exists. And instead of adding it again, you will need to replace the existing arg.

Comment by Karel Piwko [ 09/Jul/13 ]

PR was sent here: https://github.com/groovy/groovy-eclipse/pull/6

Comment by Andrew Eisenberg [ 09/Jul/13 ]

Thanks for the quick turn around. Taking a look at it now. I have the following comments:

  1. You have a portion where you preserve double quotes if previous value was quoted. Why is this necessary?
  2. There is a problem that if the new arg has a key but no value and the old one has both a key and a value (or the reverse), then the argument list will be messed up.
  3. The pull request didn't merge clean for me. Make sure to rebase the changes off of master.

After you address these issues, I will merge the pull request.

Comment by Karel Piwko [ 10/Jul/13 ]

Hey Andrew,

1. I put it there as original implementation was double quoting to differ the least possible way. I'm not sure that quoting is actually necessary here, for instance maven compiler plugin ignores quoting and people can quote in xml if really required. If I quoted all compiler arguments, -target "1.6" was not valid, so I did that check to keep -target 1.6. I'd personally prefer to remove quoting altogether if that works for you.

2. If a new arg has a key but misses value, it is ignored. If old arg has key but misses value, while new one defines the value, it really might be messed up. Proper solution is I guess not to use List as intermediate format. I'll fix that.

3. I'll force push branch rebased on top of current master.

Comment by Karel Piwko [ 10/Jul/13 ]

PR updated w.r.t. my previous comments. Quoting was removed.

Comment by Andrew Eisenberg [ 10/Jul/13 ]

Thanks. Nice work. It is merged!

Comment by Andrew Eisenberg [ 10/Jul/13 ]

Deployed a new 2.9.0-01-SNAPSHOT.





[GRECLIPSE-1656] Remove Groovy 1.7 support Created: 02/Jul/13  Updated: 05/Jun/14  Resolved: 05/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Groovy 1.7 is old enough that we should no longer support it.



 Comments   
Comment by Kris De Volder [ 05/Jun/14 ]

This was done a while ago. Resolving.





[GRECLIPSE-1653] Error compiling grails code Created: 27/Jun/13  Updated: 02/Jul/13  Resolved: 02/Jul/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
  1. Check out this hash from grails-core ff6f6e249531791efec6b3e38d3d9fccd48f8a11
  2. run gradlew eclipse on command line
  3. import all projects into eclipse
  4. open org.grails.plugins.web.rest.render.hal.HalDomainClassJsonRendererSpec

Get this error on incremental and full builds:

Couldn't find binding for 'org.grails.plugins.web.rest.render.hal.AuthorController$_show_closure8': do you maybe have a duplicate type around?

java.lang.RuntimeException: Couldn't find binding for 'org.grails.plugins.web.rest.render.hal.AuthorController$_show_closure8': do you maybe have a duplicate type around?
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1695)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:722)


 Comments   
Comment by Andrew Eisenberg [ 27/Jun/13 ]

Something about the @Resource annotation is not being liked. Deleted everything except this:

package org.grails.plugins.web.rest.render.hal

import grails.rest.Resource

@Resource
class Author { }

Remove @Resource and errors go away.

Comment by Andrew Eisenberg [ 27/Jun/13 ]

The org.grails.plugins.web.rest.transform.ResourceTransform explicitly adds Controller classes to the current module node. This is confusing greclipse since it assumes that things sharing modules also share files.

See line 248:

ast.classes.add(newControllerClassNode)
Comment by Andrew Eisenberg [ 27/Jun/13 ]

Sure enough, when that line is commented out the error goes away.

Comment by Andrew Eisenberg [ 28/Jun/13 ]

The transform adds a synthetic class to the module and it has no source component. In a case like this, it is correct that the class has no binding. We may just need to write the bytes to disk if we find this.

Comment by Andrew Eisenberg [ 28/Jun/13 ]

No. That won't work. We need to generate a binding based on the ClassNode.

Comment by Andrew Eisenberg [ 02/Jul/13 ]

Pushed a fix for this: https://github.com/groovy/groovy-eclipse/commit/5762f249b69130d74e926ff480a7a0b3674d5d70

Things seem to work and grails tests are passing. The root cause is the missing sourceTypeBinding. We are able to avoid accessing it in one place and this is what is making things work. However, I am concerned in that there may be other situations where the sourceTypeBinding is accessed. So far, I can't reproduce this, but it may happen in the future.

Comment by Andrew Eisenberg [ 02/Jul/13 ]

Tentatively resolving this one. Getting this bug fixed for 2.8.0 is important since without this fix, the new @Resource transform for Grails 2.3.0 will not work.





[GRECLIPSE-1652] Compiler mismatch errors should be removed when the project compiler level changes Created: 27/Jun/13  Updated: 27/Jun/13  Resolved: 27/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It used to be that as soon as the compiler level changed, any mismatch for the project would be recomputed, but that stopped working a little while ago. Need to fix this.



 Comments   
Comment by Andrew Eisenberg [ 27/Jun/13 ]

Now working.





[GRECLIPSE-1651] Disable "monospace font" for junit view since it isn't working Created: 27/Jun/13  Updated: 27/Jun/13  Resolved: 27/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Tried for a long time to get this working consistently, but there is just no way that I can get this working in groovy-eclipse without actually changing the junit plugin. I should probably submit a patch for JDT to get this in there.



 Comments   
Comment by Andrew Eisenberg [ 27/Jun/13 ]

Done. Preference item is still there, but it is deprecated and disabled.

Raised a JDT bug and will work on a patch for this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=411794





[GRECLIPSE-1650] Groovy script launcher has problems if groovy on classpath is different from that of the environemnt Created: 26/Jun/13  Updated: 27/Jun/13  Resolved: 27/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If you have groovy 2.1.5 on your classpath, but have 2.1.1 as your compiler in the workbench, launching a script will fail.

This is because the script launch config automatically adds a link to the groovyStarter.conf file. Removing this line will allow the script to run.

Do we even need the groovyStarter.conf reference?



 Comments   
Comment by Andrew Eisenberg [ 27/Jun/13 ]

Removing the groovy-starter.conf from being added by default to the groovy script launch configuration.





[GRECLIPSE-1649] When using groovy-eclipse-compiler force an explicit version of groovy-eclipse-batch Created: 26/Jun/13  Updated: 26/Jun/13  Resolved: 26/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, if there is no explicit groovy-eclipse-batch version specified, the most recent is used. This is problematic since new releases may cause changes in builds even if all else stays the same.



 Comments   
Comment by Andrew Eisenberg [ 26/Jun/13 ]

Fixed. Now, you must explicitly specify a version of groovy-eclipse-batch in your pom. If you don't a friendly error message comes out. See http://stackoverflow.com/questions/17305349/making-a-requiring-an-explicit-maven-dependency-on-a-transitive-dependency?noredirect=1#comment25105924_17305349 for more details on implementation.





[GRECLIPSE-1648] NPE in ContentTypeUtils in mvn build Created: 25/Jun/13  Updated: 25/Jun/13  Resolved: 25/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Blocker
Reporter: Steve Loughran Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

<gmavenVersion>1.5</gmavenVersion>
<gmavenProviderSelection>2.0</gmavenProviderSelection>
<groovy.version>2.1.3</groovy.version


Number of attachments : 0

 Description   

NPE in ContentTypeUtils during an mvn install. This is new since yesterday -since then I've updated some dependencies, and moved from a constructor of some (java) objects to a factory in a static groovy method



 Comments   
Comment by Steve Loughran [ 25/Jun/13 ]

stack. Sorry about the way mvn is cropping the relevant bits. Code is not (yet) public; I'll tag the version with this problem so that it may be recreatable (mvn nondeterminism notwithstanding)

INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
java.lang.ExceptionInInitializerError
	at org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.dietParse(MultiplexingParser.java:43)
	at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:775)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:481)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4130)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1689)
	at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.compile(GroovyEclipseCompiler.java:243)
	at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:605)
	at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NullPointerException
	at org.eclipse.jdt.groovy.core.util.ContentTypeUtils.<clinit>(ContentTypeUtils.java:45)
	... 30 more
Comment by Steve Loughran [ 25/Jun/13 ]

Rolling back code to yesterday across all dependencies hasn't fixed this -nor does moving to groovy 2.1.5. dependency list for the compiler is

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project hoya: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile: java.lang.ExceptionInInitializerError: null
[ERROR] -----------------------------------------------------
[ERROR] realm =    plugin>org.apache.maven.plugins:maven-compiler-plugin:2.3.2
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/Users/stevel/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar
[ERROR] urls[1] = file:/Users/stevel/.m2/repository/org/codehaus/groovy/groovy-eclipse-compiler/2.7.0-01/groovy-eclipse-compiler-2.7.0-01.jar
[ERROR] urls[2] = file:/Users/stevel/.m2/repository/org/codehaus/groovy/groovy-eclipse-batch/2.1.5-02/groovy-eclipse-batch-2.1.5-02.jar
[ERROR] urls[3] = file:/Users/stevel/.m2/repository/org/apache/xbean/xbean-reflect/3.4/xbean-reflect-3.4.jar
[ERROR] urls[4] = file:/Users/stevel/.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar
[ERROR] urls[5] = file:/Users/stevel/.m2/repository/commons-logging/commons-logging-api/1.1/commons-logging-api-1.1.jar
[ERROR] urls[6] = file:/Users/stevel/.m2/repository/com/google/collections/google-collections/1.0/google-collections-1.0.jar
[ERROR] urls[7] = file:/Users/stevel/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar
[ERROR] urls[8] = file:/Users/stevel/.m2/repository/org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar
[ERROR] urls[9] = file:/Users/stevel/.m2/repository/org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar
[ERROR] urls[10] = file:/Users/stevel/.m2/repository/org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar
[ERROR] urls[11] = file:/Users/stevel/.m2/repository/org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
[ERROR] 

Comment by Piotr Jarzemski [ 25/Jun/13 ]

Try to specify groovy-eclipse-batch explicitly in dependency of maven-compiler-plugin in your pom.xml

 
...
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>2.3.2</version>
          <configuration>
            <source>1.6</source>
            <target>1.6</target>
            <compilerId>groovy-eclipse-compiler</compilerId>
          </configuration>
          <dependencies>
            <dependency>
              <groupId>org.codehaus.groovy</groupId>
              <artifactId>groovy-eclipse-compiler</artifactId>
              <version>2.7.0-01</version>
            </dependency>
            <dependency>
                <groupId>org.codehaus.groovy</groupId>
                <artifactId>groovy-eclipse-batch</artifactId>
                <version>2.0.4-04</version>
            </dependency>
          </dependencies>
        </plugin>
...
Comment by Arnaud Heritier [ 25/Jun/13 ]

Hi

Same thing here.
All my builds using the groovy compiler in maven are broken since today with this error :

[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
java.lang.ExceptionInInitializerError
	at org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.dietParse(MultiplexingParser.java:43)
	at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:775)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:485)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4130)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1689)
	at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.compile(GroovyEclipseCompiler.java:243)
	at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:789)
	at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
	at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:326)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
	at org.eclipse.jdt.groovy.core.util.ContentTypeUtils.<clinit>(ContentTypeUtils.java:45)
	... 38 more

Full logs are here : https://ci.exoplatform.org/job/platform-public-distributions-master-ci/460/console
In my project I'm using groovy 2.1.4, and the groovy-eclipse-compiler 2.7.0-01 (https://github.com/exoplatform/platform-public-distributions/blob/master/plf-extensions-manager/pom.xml)
Yesterday you published new versions in central of groovy-eclipse-batch and they are automatically used by the compiler because of the usage of a range (that's why it is dangerous to use them ).

<dependency>
  <groupId>org.codehaus.groovy</groupId>
  <artifactId>groovy-eclipse-batch</artifactId>
  <version>[1.7.10-02,1.7.10-99],[1.8.2-01,9.9.9)</version> 
</dependency>

The result is

  • groovy-eclipse-compiler 2.7.0-01 + groovy-eclipse-batch 2.1.5-02 = KO
  • groovy-eclipse-compiler 2.7.0-01 + groovy-eclipse-batch 2.1.5-01 = KO
  • groovy-eclipse-compiler 2.7.0-01 + groovy-eclipse-batch 2.1.3-01 = OK

The workaround is to enforce the version of groovy-eclipse-batch to use.

Please could you deploy a fix ASAP to not break the build of all your users of groovy-eclipse-compiler 2.7.0-01

Cheers

Comment by Steve Loughran [ 25/Jun/13 ]

thanks to the suggestions above, my build is working again. For others encountering this, here is my full compiler plugin declaration

      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
          <compilerId>groovy-eclipse-compiler</compilerId>
          <!-- set verbose to be true if you want lots of uninteresting messages -->
          <!-- <verbose>true</verbose> -->
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.7.0-01</version>
          </dependency>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-batch</artifactId>
            <version>2.1.3-01</version>
          </dependency>
        </dependencies>
      </plugin>

Looks to me like there's a regression in the latest artifacts, and those of us in the EU hit it first due to TZ differences.

Comment by Andrew Eisenberg [ 25/Jun/13 ]

The new groovy-eclipse-batch versions are somehow calling into ContentTypeUtils too early. This is working for me with the 2.8.0-01-SNAPSHOT version.

I'll find out why it is not working for the 2.7.0

In future releases of groovy-eclipse-compiler, I make it so that the dependency with groovy-eclipse-batch must be specified explicitly in client code.

Comment by Andrew Eisenberg [ 25/Jun/13 ]

Should be fixed momentarily. Uploading the new -03 batch artifacts now.

Comment by Andrew Eisenberg [ 25/Jun/13 ]

Confirmed this is fixed. with 2.1.5-03 and 2.0.7-03 and groovy-eclipse-compiler 2.7.0-01.

Comment by Andrey Paramonov [ 25/Jun/13 ]

Thanks for fast resolution.





[GRECLIPSE-1647] Problem searching for constructor references Created: 21/Jun/13  Updated: 28/Jun/13  Resolved: 28/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: Search
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Constructors are not being found through search. Simple example:

Java or Groovy class:

public class DeclarationClass {
	public DeclarationClass(String barcodeMask) {}
	public DeclarationClass(int x) {}
}

Groovy class:

class ReferenceClass {
	def method()	 {
		new DeclarationClass(3)
		new DeclarationClass('')
	}
}

Do a search for either constructor and nothing is found. However, do a search for class references and the constructors are found.



 Comments   
Comment by Andrew Eisenberg [ 28/Jun/13 ]

Fixed with regression tests.

We are not distinguishing between overloaded constructor calls. All references are found when any reference is searched for.





[GRECLIPSE-1646] Provide groovy-eclipse-batch for groovy 2.0.7 and groovy 2.0.8 Created: 20/Jun/13  Updated: 26/Jun/13  Resolved: 26/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Maven integration
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Damir Murat Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I don't want to complain too much because I can only guess how hard is to keep various bits and pieces in sync.

However, current situation with groovy, grails, groovy-eclipse-batch versions is not consistent, to say at least. STS is promoted as a great tool for developing grails applications. If someone is using latest released grails version (2.2.2), which uses groovy 2.0.8, he will soon discover that STS supports only groovy 2.0.7, and that groovy-eclipse-batch supports only 2.0.6. Since groovy-eclipse-compiler is preferred option for compiling groovy with maven, all this version clashes and inconsistencies is not something that helps introducing grails and groovy in various organizations (I'm talking here from my own experience). With current situation groovy/grails in maven environment looks somewhat immature and it is hard to explain otherwise to a project manager.

Please, could you take care to keep groovy/grails/groovy-eclipse-batch versions in sync? As a start, can you please update groovy-eclipse-batch to groovy 2.0.7 and 2.0.8?

Tnx

Best regards,
Damir Murat



 Comments   
Comment by Andrew Eisenberg [ 20/Jun/13 ]

I'm having trouble deploying to maven central right now, so can't publish anything new just yet. When I do, I will get 2.0.7 and 2.1.5 published.

Comment by Damir Murat [ 20/Jun/13 ]

Thank you very much. I really appreciate it.

Comment by Andrew Eisenberg [ 24/Jun/13 ]

2.0.7-01 and 2.1.5-01 versions of groovy-eclipse-batch are now available.

Comment by Andrey Paramonov [ 24/Jun/13 ]

Any idea why the following error might happen?

java.lang.NoClassDefFoundError: org/eclipse/core/runtime/content/IContentTypeManager$IContentTypeChangeListener
	at org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.dietParse(MultiplexingParser.java:43)
	at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:775)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:485)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4130)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1689)
	at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.compile(GroovyEclipseCompiler.java:243)
	at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:789)
	at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.ClassNotFoundException: org.eclipse.core.runtime.content.IContentTypeManager$IContentTypeChangeListener
	at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
	... 30 more

We got it right after this batch jar was downloaded from remote repo. Nothing changed in our code.

Comment by Andrew Eisenberg [ 24/Jun/13 ]

Yes. I think I know what the problem is. We added a new dependency to groovy-eclipse as a plugin, but this was not reflected in our maven build scripts. I will fix it.

Comment by Andrew Eisenberg [ 24/Jun/13 ]

reopening issue

Comment by Andrew Eisenberg [ 24/Jun/13 ]

2.0.7-02 and 2.1.5-02 versions of groovy-eclipse-batch are now available. Keeping this issue opened until it is confirmed fixed.

Comment by Damir Murat [ 25/Jun/13 ]

With 2.0.7-02 I get following error

[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
java.lang.ExceptionInInitializerError
        at org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.dietParse(MultiplexingParser.java:43)
        at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:775)
        at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
        at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:485)
        at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4130)
        at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1689)
        at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.compile(GroovyEclipseCompiler.java:243)
        at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:678)
        at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NullPointerException
        at org.eclipse.jdt.groovy.core.util.ContentTypeUtils.<clinit>(ContentTypeUtils.java:45)
        ... 30 more

Build works with 2.0.6-01

Comment by Andrew Eisenberg [ 25/Jun/13 ]

Should be fixed momentarily. See GRECLIPSE-1648.

Comment by Damir Murat [ 26/Jun/13 ]

2.0.7-03 works for me. Tnx.

Comment by Andrew Eisenberg [ 26/Jun/13 ]

Thanks for the response.





[GRECLIPSE-1645] scope not set correctly for doubly nested anonymous types Created: 19/Jun/13  Updated: 19/Jun/13  Resolved: 19/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Grails has just introduced a case of this where a class has an anonymous inner class which in turn has a further anonymous inner class. We are only fixing scopes up one level down so grails-core master fails this morning due to this.



 Comments   
Comment by Andy Clement [ 19/Jun/13 ]

fixed





[GRECLIPSE-1644] Problems using groovy-eclipse-compiler with jenkins project Created: 13/Jun/13  Updated: 05/Jun/14  Resolved: 05/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There are several problems with using the groovy-eclipse-compiler and was originally reported under GMAVEN-105 and also GRECLIPSE-1076.

But, having a deeper look, it seems that there is a more fundamental problem. The GEC is just spitting out the messages from the compiler without filtering them or parsing them into proper CompilerMessages that maven understands. This has several remaifications:

  1. Warnings are sent to the console regardless of whether or not warnings are enabled or disabled.
  2. The entire list of messages are not returned as part of the compiler result.
  3. file names and line numbers are missed.

We should be parsing this information correctly.



 Comments   
Comment by Andrew Eisenberg [ 13/Jun/13 ]

I have pushed a 2.8.0-01-SNAPSHOT to http://nexus.codehaus.org/snapshots/. This fixes the message parsing problems. Warnings will not be shown unless they are explicitly enabled by <showWarnings>true</showWarnings> in the maven-compiler-plugins configuration. So, the alleviates many of the annoyances.

For the Jenkins build in particular, I see some things that are not really possible to fix since they are limited by JDT:

  1. Annotation processor messages are always spit out as warnings, and not simply "notes". The JDT batch compiler only recognizes warnings and errors. So, there is no other way around without making changes to the way JDT works.
  2. Similarly, package colliding with type warnings (GRECLIPSE-1076) are defined by JDT. So, again, I can't change this without making semantic changes to JDT.

Since both of these issues manifest themselves as warnings and will be filtered by default, I am less concerned about them.

Comment by Andrew Eisenberg [ 13/Jun/13 ]

Jesse, could you try out the new version of the compiler and let me know if this works for you?

Things seem to be compiling and testing properly (at least in the core bundle). The build is failing during the war stage, but it seems to be unrelated to compiling.

Comment by Jesse Glick [ 14/Jun/13 ]

No time to work on it at the moment unfortunately, but noted at: https://github.com/jenkinsci/jenkins/pull/806

Comment by Kris De Volder [ 05/Jun/14 ]

From what I read above, it sounds like what could be fixed was fixed.
I'm closing this issue now.

Jesse, if you think there's more that needs to be done, feel free to add comments and reopen the issue again.





[GRECLIPSE-1642] Switching workspace compiler level from "unspecified" to "2.0" leads to org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object Created: 12/Jun/13  Updated: 09/Oct/13  Resolved: 19/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Blocker
Reporter: Jörg Thönnes Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

2.8.0.xx-20130603-1200-e42 (snapshot build)


Attachments: Text File console-log.txt     Text File Console-log-with-clean.txt     Text File Console-log-with-trace-compiler-start-enabled.txt     Text File Eclipse-configuration.txt     Text File empty-workspace.log     Text File GRECLIPSE-1642-Eclipse.log     PDF File Installation-of-Eclipse-3.8.2-Juno-2013-06-07-130613-1447-28.pdf     PNG File Update-JDT-Patch-already-installed.png    
Number of attachments : 8

 Description   

Created new Eclipse shared installation with latest Groovy snapshot build from last week.

Now I tried to switch the workspace compiler level from "unspecified" to "2.0". The restart failed, i.e. Eclipse restarted and stopped then.

Then I tried to restart Eclipse again. Did not work.
With another workspace, Eclipse could start.

Looking at the Eclipse .log I see this exception:

Eclipse .log
!ENTRY org.eclipse.ui 4 0 2013-06-12 12:48:22.585
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.core.runtime.InvalidRegistryObjectException: Invalid registry object
    at org.eclipse.core.internal.registry.RegistryObjectManager.basicGetObject(RegistryObjectManager.java:273)
...

Detailed log will be attached.

I am still investigating but posting this issue just in case it is already known or even solved. Thanks.



 Comments   
Comment by Jörg Thönnes [ 12/Jun/13 ]

Attached Eclipse .log with full exception trace.

Comment by Jörg Thönnes [ 12/Jun/13 ]

Switched back to previous version "2.8.0.xx-20130314-1300-e42":

  • This is working.

Console output as normal:

Starting Groovy-Eclipse compiler hook.  Specified compiler level: 2.0

To me it appears as if the switch of the workspace compiler level destroyed something in the "registry."

Comment by Jörg Thönnes [ 12/Jun/13 ]

Anything you want me to try or to look up and attach?

Comment by Jörg Thönnes [ 12/Jun/13 ]

Upgraded to the latest snapshot build "2.8.0.xx-20130611-0800-e42" resulted in the same error:

  • Start with new workspace
  • Switch compiler to 2.0
  • Restart fails.
Comment by Jörg Thönnes [ 12/Jun/13 ]

Attached .log from the new workspace.

Comment by Jörg Thönnes [ 12/Jun/13 ]

Will now try the last milestone build...

Comment by Jörg Thönnes [ 12/Jun/13 ]

Also tested with latest milestone build "2.8.0.xx-20130531-0900-e42":

  • Same result: Eclipse stops on restart. And cannot be started again.

To me it seems that the JDT patch was not uninstalled. How could I do that?

Comment by Jörg Thönnes [ 12/Jun/13 ]

Here you can see that the JDT patch cannot be installed after uninstalled the complete GRECLIPSE features. If I want to re-install from the milestone site, the JDT patch is greyed out as if it had been already installed.

Comment by Jörg Thönnes [ 12/Jun/13 ]

Now the only remaining workaround is to do a complete rollback and create the shared installation again...

Comment by Andrew Eisenberg [ 12/Jun/13 ]

If you ever get the InvalidRegistryObjectException, you can restart Eclipse with the -clean option and the error should go away.

In general, the reason why this problem happens is that the groovy core compiler level is chosen before the CompilerChooser is run. The CompilerChooser is the plugin that chooses which compiler to use and it must be invoked before the groovy compiler plugin is started. If it happens too late, then the started compiler must be shut down and a new one started. This leaves some dangling registry objects and that is where the exception comes from.

Launching eclipse with -clean will wipe pout the configuration area and start with the default groovy compiler.

Now, on to your specific problem. There is something that is causing the compiler to be loaded before the CompilerChooser is run. Do you have any third party plugins installed? Some less well behaved plugins will load the JDT tools (and hence the Groovy compiler) too early and may cause this problem.

Please go to Help -> About GGRS -> Installation details -> Configuration. And paste the page here.

Comment by Jörg Thönnes [ 13/Jun/13 ]

Andrew, thanks for your prompt help.

Re: eclipse -clean:

This actually did the job, but it seems I have to call it always. So running "eclipse -clean", stopping and running plain eclipse afterwards showed the old faulty behaviour, ie eclipse stopped.

I am sure I get you some steps to reproduce this issue locally since:

1. I can reproduce it easily with a fresh workspace.
2. I have detailed installation instruction I could attach for you.

Will do some more research now...

Comment by Jörg Thönnes [ 13/Jun/13 ]

OK, removing the support for Groovy 2.1 is a good workaround for us until this is resolved:

Eclipse console output
Starting Groovy-Eclipse compiler resolver.  Specified compiler level: 2.0
Specified version not found, using 2.0.7.xx-20130607-1000-e42 instead.
Comment by Jörg Thönnes [ 13/Jun/13 ]

Here is the minimal installation where this issue occurs.

Steps to reproduce

  • Create installation:
    • based on eclipse-SDK-3.8.2-linux-gtk-x86_64.tar.gz
    • will attach detailed instructions
  • Remove $HOME/workspace
  • Start Eclipse
  • Switch compiler to 2.0.7
  • Restarting fails
  • Manual start also fails
Comment by Jörg Thönnes [ 13/Jun/13 ]

Attached our stripped-down installation instruction to get the Eclipse version which shows this issue.

Comment by Jörg Thönnes [ 13/Jun/13 ]

Please also note that we use a shared installation if that matters:

  • Make Eclipse installation r/o.
  • Starting Eclipse creates a local $HOME/.eclipse directory to store global configuration (not related to any workspace).
  • We are running on 64bit Linux: Ubuntu 12.04 LTS with current updates.

Now you should be able to reproduce this issue just in case the attached configuration file is not sufficient.

Comment by Andrew Eisenberg [ 13/Jun/13 ]

Thanks for the detailed instructions. I will try this.

Comment by Andrew Eisenberg [ 13/Jun/13 ]

Followed installation instructions, but could not reproduce. Only difference is that I am on mac. I'll keep looking.

Comment by Andrew Eisenberg [ 13/Jun/13 ]

I have spent a while trying to reproduce, but still can't. As I said, the reason is likely that the groovy compiler bundle is starting earlier than expected. If we can gather a stack trace when it is being started, we can get an idea of what is causing the bundle to start early. So, I am adding a flag that will cause the compiler bundle to produce a bunch of debug info.

If you get a chance, can you upgrade to the latest greclipse snapshot and add the following system property to your start:

-Dgreclipse.debug.trace_compiler_start=true

This will produce output like this to the console:

------------
GRECLIPSE-1642: stack trace and other info as Groovy-compiler starts
org.codehaus.groovy.eclipse.compilerResolver state: ACTIVE
org.eclipse.jdt.core state: ACTIVE
java.lang.Exception
	at org.codehaus.groovy.activator.GroovyActivator.start(GroovyActivator.java:54)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
...

Keep an eye out for this and please paste it here. You will just need to wait for an hour or two until the build I just kicked off makes its way to the update site.

Comment by Jörg Thönnes [ 14/Jun/13 ]

OK, just checked that happens both for the normal and the shared (r/o) installation.

At the moment, I get "Connection timed out" on updating from the snapshot site so I will try this later.

Note that I am at GMT+2 so when you post a build I still have some hours to sleep

Comment by Jörg Thönnes [ 14/Jun/13 ]

No chance to install the snapshot, even with downloaded ZIP archive.

During the update the connection to "downloads.sourceforge.net" seems to time out all the day...

Will continue on Monday.

Comment by Andrew Eisenberg [ 14/Jun/13 ]

Hmmm...we don't host anything on downloads.sourceforge.net. Next time try de-selecting "Contact all update sites...". It may be that you have an unrelated update site that is broken.

Comment by Jörg Thönnes [ 18/Jun/13 ]

Attached console log with "trace_compiler_start" enabled.
This stack trace is triggered as soon as I open the Groovy preferences page.
After switching the compiler and restarting this is not touched.

Even another restart does not help.

Comment by Jörg Thönnes [ 18/Jun/13 ]

An extra "-clean" does the job here: Eclipse starts successfully and on opening the Groovy preferences,
the below stack trace is shown.

Comment by Jörg Thönnes [ 18/Jun/13 ]

Another restart without "-clean" also works. But note, that I did these checkeds with a normal read/writable installation (not the shared one).

Any further points to test here?

Comment by Andrew Eisenberg [ 18/Jun/13 ]

Thanks for trying this out and getting back to me.

Attached console log with "trace_compiler_start" enabled.
This stack trace is triggered as soon as I open the Groovy preferences page.

This is expected when you have an empty workspace.

After switching the compiler and restarting this is not touched.

Even another restart does not help.

I'm not sure what you mean here. Are you saying that you have the same problem as before? Once you switch the compiler you cannot restart?

Comment by Andrew Eisenberg [ 18/Jun/13 ]

The stack trace you show is what I would expect to see in an empty workspace and things are happening properly (ie- the compilerResolver is behaving correctly).

When the workspace does not start, do you have any output to the console? If the answer is no, then there is something that is causing the errors before the groovy compiler bundle can be started, which is not what I expected.

What happens if you start with both the -clean and the -groovy.compiler.level 18 option in your eclipse.ini? Ie- add this before your vmargs entry:

-clean
-groovy.compiler.level
18

(or substitute your favorite compiler version for 18)

Wish I had some more concrete answers for you, but since there is a work around, it might be best to keep doing that for now until we can find a better solution.

Comment by Jörg Thönnes [ 18/Jun/13 ]

No, there is no extra output (e.g. the stack trace). So it seems that the option code is not triggered at all.

Do you know some general Eclipse bundle / class-loading debugging in order to find out what is going on?

Will try the suggested command line arguments tomorrow as I am answering from home now.

Comment by Jörg Thönnes [ 19/Jun/13 ]

Starting with the above options works fine:

$ /opt2/Eclipse/3.8.2-Juno-2013-06-07-Minimal64bitGRECLIPSE-1642Local/eclipse/eclipse -clean -groovy.compiler.level 18 -eclipse.password /home/jt/.eclipse/Eclipse.password     -keyring /home/jt/.eclipse-keyring/.keyring     -vmargs     -Xmx1024m     -XX:PermSize=128m     -XX:MaxPermSize=256m     -XX:ReservedCodeCacheSize=64m     -Xverify:none     -Djava.net.preferIPv4Stack=true     -Dfile.encoding=ISO-8859-1     -Dsun.jnu.encoding=ISO-8859-1     -Dorg.eclipse.swt.internal.gtk.disablePrinting     -Dgreclipse.debug.trace_compiler_start=true
Xlib:  extension "RANDR" missing on display ":0.0".
Starting Groovy-Eclipse compiler resolver.  Specified compiler level: 1.8
Comment by Jörg Thönnes [ 19/Jun/13 ]

But we specify the compiler level as command line options, it is also taken on restart if I change the options to 2.0 again in the preferences. This is a bit surprising...

Then I stop and start again without -clean and compiler level and it starts with 2.0 (as requested in the preferences) and is running fine.

Comment by Jörg Thönnes [ 19/Jun/13 ]

Let me know any steps you want to me to execute – I am happy do some "remote" debugging

Comment by Andrew Eisenberg [ 19/Jun/13 ]

Command line arguments always override a preference setting. At this point, I am a little confused as to what is working and what is not. It seems like there is enough of a workaround for you to get things going in the shared environment, but please explain to me if there isn't.

If you are still around and want to chat, feel free to ping me on skype @werdnagreb.

Comment by Andrew Eisenberg [ 19/Jun/13 ]

Thanks for chatting Jorg. We can't reproduce this problem right now. Here's a summary in case anyone sees this again:

  1. This might be related to being in a shared install.
  2. Try starting Eclipse with the -groovy.compiler.level command line argument instead of using the preferences page
  3. Uninstall all other versions of the compiler except for the one that you need.
  4. Running with -clean may also help.
Comment by Andrew Eisenberg [ 19/Jun/13 ]

Can no longer reproduce. Resolving this issue.

Comment by Lari Hotari [ 08/Oct/13 ]

Similar issue: GRECLIPSE-1328 . I'm getting this with STS 3.4.0M1 .

Had to do this to get STS running again:

cd WORKSPACE_DIR
rm .metadata/.plugins/org.eclipse.core.runtime/.settings/org.codehaus.groovy.eclipse.compilerResolver.prefs
rm -rf .metadata/.plugins/org.eclipse.ui.workbench
rm -rf .metadata/.plugins/org.eclipse.m2e.core
Comment by Lari Hotari [ 09/Oct/13 ]

Comment in https://github.com/groovy/groovy-eclipse/blob/master/base/org.codehaus.groovy.eclipse.compilerResolver/src/org/codehaus/groovy/frameworkadapter/util/ResolverActivator.java#L44

// There is a small window where the chooser can be initialized.
// It has to be after the workspace has started (in order to ensure
// the choose workspace dialog still shows) but before JDT is initialized
// (so that the groovy bundles aren't loaded).

// The service listener is called synchronously as the resources bundle is actived

It looks like this solution doesn't work for STS 3.4.0 on Eclipse 3.8 .





[GRECLIPSE-1641] Greclipse plugin seems to break JDT content assist. Created: 10/Jun/13  Updated: 10/Jun/13  Resolved: 10/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Ondrej Ilcik Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse.buildId=M20120208-0800
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=cs_CZ
Framework arguments: -product org.eclipse.epp.package.rcp.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.rcp.product


Attachments: PNG File eclipse_with_greclipse_installed.png     PNG File plain_eclipse.png    
Issue Links:
Duplicate
duplicates GRECLIPSE-1570 Conflicts between greclipse and scala... Resolved
Number of attachments : 2

 Description   

After greclipse installation, JDT content assist sometimes fails throwing NPE.

Step to reproduce (valid at least for Eclipse for RCP Indigo and Greclipse 2.7.2)
1) Create plain Java project with a simple class (see screenshots)
2) Inside the method, starts writing this code

new Thread(new Runn

3) Press Ctrl+Space to get some completion choices, expection to see Runnable etc. This works prior to Greclipse installation.
4) NPE is thrown with the following stracktrace:

 
java.lang.NullPointerException
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:539)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
	at org.eclipse.jdt.internal.codeassist.InternalCompletionProposal.findConstructorParameterNames(InternalCompletionProposal.java:247)
	at org.eclipse.jdt.internal.codeassist.InternalCompletionProposal.findParameterNames(InternalCompletionProposal.java:1423)
	at org.eclipse.jdt.ui.text.java.CompletionProposalLabelProvider.appendUnboundedParameterList(CompletionProposalLabelProvider.java:113)
	at org.eclipse.jdt.ui.text.java.CompletionProposalLabelProvider.createAnonymousTypeLabel(CompletionProposalLabelProvider.java:519)
	at org.eclipse.jdt.ui.text.java.CompletionProposalCollector.createAnonymousTypeProposal(CompletionProposalCollector.java:694)
	at org.eclipse.jdt.ui.text.java.CompletionProposalCollector.createJavaCompletionProposal(CompletionProposalCollector.java:453)
	at org.eclipse.jdt.internal.ui.text.java.FillArgumentNamesCompletionProposalCollector.createJavaCompletionProposal(FillArgumentNamesCompletionProposalCollector.java:65)
	at org.eclipse.jdt.ui.text.java.CompletionProposalCollector.accept(CompletionProposalCollector.java:250)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.findAnonymousType(CompletionEngine.java:4841)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.findConstructorsOrAnonymousTypes(CompletionEngine.java:5537)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.findTypesFromExpectedTypes(CompletionEngine.java:10857)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.findTypesAndPackages(CompletionEngine.java:10459)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.completionOnSingleTypeReference(CompletionEngine.java:3251)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:1653)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:1875)
	at org.eclipse.jdt.internal.core.Openable.codeComplete(Openable.java:130)
	at org.eclipse.jdt.internal.core.CompilationUnit.codeComplete(CompilationUnit.java:358)
	at org.eclipse.jdt.internal.core.CompilationUnit.codeComplete(CompilationUnit.java:346)
	at org.eclipse.jdt.internal.ui.text.java.JavaCompletionProposalComputer.internalComputeCompletionProposals(JavaCompletionProposalComputer.java:244)
	at org.eclipse.jdt.internal.ui.text.java.JavaCompletionProposalComputer.computeCompletionProposals(JavaCompletionProposalComputer.java:206)
	at org.eclipse.mylyn.internal.java.ui.editor.FocusedJavaAllProposalComputer.computeCompletionProposals(FocusedJavaAllProposalComputer.java:96)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:318)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:267)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:283)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:243)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1830)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:488)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482)
	at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1656)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:183)
	at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185)
	at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
	at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
	at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1509)
	at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640)
	at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4528)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2531)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)


 Comments   
Comment by Andrew Eisenberg [ 10/Jun/13 ]

This has been fixed with GRECLIPSE-1570. Please upgrade to the nightly version of groovy-eclipse. See here:

http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-DevelopmentBuilds

Comment by Andrew Eisenberg [ 10/Jun/13 ]

This issue has already been fixed in GRECLIPSE-1570. Please update to the latest snapshot build to fix. See here:

http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-DevelopmentBuilds

Comment by Andrew Eisenberg [ 10/Jun/13 ]

Duplicate of GRECLIPSE-1570





[GRECLIPSE-1639] Compiler crash during build of gaelyk project Created: 07/Jun/13  Updated: 07/Jun/13  Resolved: 07/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

To reproduce:

  1. Download Gaelyk template project from here: https://gaelyk.appspot.com/download
  2. import into a workspace as a gradle project
  3. create a file like this:
    import groovyx.gaelyk.datastore.Entity
    
    @Entity
    class Avatar{
    
    }
    
  4. Whitespace change and you get the following error marker stack trace:
General error during semantic analysis: nyi class org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding

java.lang.IllegalStateException: nyi class org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.configureType(JDTClassNodeBuilder.java:72)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createJDTClassNode(JDTResolver.java:475)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.convertToClassNode(JDTResolver.java:454)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.createExpressionFor(JDTAnnotationNode.java:186)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.createExpressionFor(JDTAnnotationNode.java:165)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.ensureMembersInitialized(JDTAnnotationNode.java:150)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.getMember(JDTAnnotationNode.java:67)
	at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.getTransformClassNames(ASTTransformationCollectorCodeVisitor.java:110)
	at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.visitAnnotations(ASTTransformationCollectorCodeVisitor.java:227)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:49)
	at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.visitClass(ASTTransformationCollectorCodeVisitor.java:84)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$1.call(ASTTransformationVisitor.java:203)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1200)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:631)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:184)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:2097)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:827)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:722)


 Comments   
Comment by Andrew Eisenberg [ 07/Jun/13 ]

As expected, this is somehow being caused by the type groovyx.gaelyk.datastore.EntityTransformation during the AST transform.

Comment by Andrew Eisenberg [ 07/Jun/13 ]

Looks like the problem is that since groovyx.gaelyk.datastore.EntityTransformation is referenced on Entity inside of an annotation, the JDT compiler does not immediately resolve that type binding. The comments mention that it needs to be resolved later. However, our bridge to the Groovy compiler never actually resolves it and then it tries to convert the binding to a ClassNode. That's where things explode.

When I force a resolve before trying to convert to a ClassNode, things seem to work. However, I don't know if this will affect anything else or negatively affect performance when things would otherwise be running smoothly.

Comment by Andrew Eisenberg [ 07/Jun/13 ]

Pushed a fix, but may back it out if things go haywire:

https://github.com/groovy/groovy-eclipse/commit/8c913701485b00d7a017332ca6004a34821c7308

Comment by Vladimír Oraný [ 07/Jun/13 ]

cool. if you need any help, just ping me.

Comment by Andrew Eisenberg [ 07/Jun/13 ]

Doesn't look like this bug is Gaelyk specific. It's just something about how Gaelyk uses and declares the AST transform.

Comment by Andrew Eisenberg [ 07/Jun/13 ]

Pushed a regression test as well. Things are behaving nicely. Marking as resolved. Will be available in next snapshot build.





[GRECLIPSE-1638] Code completion and highlight inside instanceof blocks Created: 04/Jun/13  Updated: 24/Jul/14  Resolved: 24/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.1.Release

Type: Improvement Priority: Major
Reporter: Vladimír Oraný Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)


Number of attachments : 0

 Description   

If I am inside instanceof block, the methods and properties from guaranteed type should not be underline as not found and also they should show up in the code completion.

For example in following snippet maximumNumberOfParameters is underlined
as unknown member but it shouldn't and also should be shown in code completion on ctrl+shift.

if(after instanceof Closure){
    if(after.maximumNumberOfParameters == 0){
        if(exp){
            throw exp
        }
        return after()
    } else if(after.maximumNumberOfParameters == 1){
        if(exp){
            throw exp
        }
        return after(ret)
    }
}


 Comments   
Comment by Andrew Eisenberg [ 05/Jun/13 ]

Too late for the 2.8.0 release, but something nice to consider for 2.9.0.





[GRECLIPSE-1637] Plugin does not behave well in case of unknown "Compiler Level" Created: 04/Jun/13  Updated: 07/Jun/13  Resolved: 07/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: David Tonhofer Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Contains invalid values.png    
Number of attachments : 1

 Description   

1) Import a groovy project using compiler level "21" (probably from a test install)
2) ".settings/org.eclipse.jdt.groovy.core.prefs" contains:

eclipse.preferences.version=1
groovy.compiler.level=21

3) After import, build fails and a red exclamation mark appears on the project.

Error log says:

java.lang.IllegalArgumentException: Invalid Groovy compiler level specified: 21
Must be one of 16, 1.6, 17, 1.7, 18, 1.8, 19, 1.9, 20, or 2.0
at org.codehaus.groovy.frameworkadapter.util.SpecifiedVersion.findVersionFromString(SpecifiedVersion.java:68)
at org.codehaus.groovy.eclipse.core.compiler.CompilerUtils.getCompilerLevel(CompilerUtils.java:378)
at org.codehaus.groovy.eclipse.core.compiler.CompilerCheckerParticipant.aboutToBuild(CompilerCheckerParticipant.java:41)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.initializeBuilder(JavaBuilder.java:590)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:167)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:726)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

4) Ok, we are gonna change the level via Properties -> Groovy Compiler

5) Unfortunately that is not possible as a model dialog appears, saying the "The currently displayed page contains invalid values"

6) You have go an edit the org.eclipse.jdt.groovy.core.prefs file manually



 Comments   
Comment by Andrew Eisenberg [ 05/Jun/13 ]

I will get this working for the 2.8.0 release.

Comment by Andrew Eisenberg [ 07/Jun/13 ]

Invalid compiler levels will no longer throw an IllegalArgumentException. They will now just spit out an error message and continue on with an UNSPECIFIED compiler level.

This will be available in next snapshot build.





[GRECLIPSE-1636] Groovy Save Action "Organize Imports" adds a nonsense import -> groovy class is not compilable anymore afterwards Created: 03/Jun/13  Updated: 03/Jun/13  Resolved: 03/Jun/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Peti Koch Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 Bit
Eclipse Juno SR 2
Groovy Eclipse 2.8.0.xx-20130531-0900-e42


Attachments: Zip Archive GroovyEclipseOrganizeImportBug.zip    
Testcase included: yes
Number of attachments : 1

 Description   

See attached eclipse project.

When I edit and save class "ch.mypackage.MyClass", an import "import somelib.obfuscated.ch" is inserted and the class is not compilable anymore.

This problems exists since at least/around summer 2012.

Workaround: Ctrl-Z after the save



 Comments   
Comment by Andrew Eisenberg [ 03/Jun/13 ]

Thanks. I'll take a look.

Comment by Andrew Eisenberg [ 03/Jun/13 ]

Ahhh...I see the problem.

There is an ambiguity with the ch name of the class defined in somelib.obfuscated.ch and the package name ch. When the editor encounters ch in the imports, it is thinking that it should be resolved to the ch class. This is really a bug in Groovy-Eclipse and it is an easy fix.

Just a warning though, lower-case class names are not really supported in Groovy. Eg, the following code will not compile:

class ch { }
class Other {
        ch x;
}

I'm guessing that the ch class is generated, but this will cause problems in Groovy if it is ever referenced directly.

Comment by Andrew Eisenberg [ 03/Jun/13 ]

Fix is pushed.





[GRECLIPSE-1635] Adding a new Groovy-like file extension is not fully recognized until restart Created: 30/May/13  Updated: 30/May/13  Resolved: 30/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Project Settings
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Go to Preferences -> General -> Content types. Add a new file extension to the Groovy source files.

You would expect that the new file extension is fully recognized by the IDE as being a groovy file, but it is not. A restart is required.



 Comments   
Comment by Andrew Eisenberg [ 30/May/13 ]

Added a IContentTypeChangeListener to ContentTypeUtils class. It flushes the file extensions cache any time there is a change in content types.

Comment by Andrew Eisenberg [ 30/May/13 ]

Fixed now.





[GRECLIPSE-1634] New option for groovy classpath container Created: 28/May/13  Updated: 28/May/13  Resolved: 28/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Project Settings
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Allow the groovy classpath container entry to specify whether or not it should be the minimal entry and contain only the groovy-all jar, or if it should container all jars in the groovy lib folder.

The reason for this bug is to avoid a bug in the gradle tooling where there is a conflict between the servlet API jar included in greclipse vs. what is required by the project.



 Comments   
Comment by Andrew Eisenberg [ 28/May/13 ]

Created a classpath attribute for the minimal groovy classpath. When the entry looks like this, only groovy-all is added to the classpath. Otherwise everything in the lib folder is added.

	<classpathentry exported="true" kind="con" path="GROOVY_SUPPORT">
		<attributes>
			<attribute name="minimal" value="true"/>
		</attributes>
	</classpathentry>

This classpath entry will be ignored for earlier versions of greclipse that do not support this feature.

I also added UI support so that this can be configured through the classpath container preferences page.





[GRECLIPSE-1633] Full build of project produces a massive number of ClassNodes that don't seem to go away Created: 24/May/13  Updated: 31/May/13  Resolved: 31/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GROOVY-6171 Memory tweaks for groovy compiler Closed
is related to GROOVY-6184 Make ClassHelper consistent in how it... Resolved
Number of attachments : 0

 Description   

During profiling, I noticed that after a full build of a project, a massive number of ClassNodes are created, but not destroyed even after the project is closed. For example, the GPars project will contrinbute about 70,000 ClassNodes after a build that do not go away when it is closed.

This does not look like a leak because the number of used ClassNodes does not increase after the first full build. But, the ClassNodes are not being cleaned up when they should.



 Comments   
Comment by Andrew Eisenberg [ 24/May/13 ]

It looks like most (all?) of these references come from fixed core types of Groovy. All of the DefaultGroovyMethods, IOGroovyMethods, java.util.List, java.util.ArrayList and other commmon, shared classes are loaded once and used between all projects. They are not cleaned up and just stick around even after they are no tbeing used directly any more (since they may be used again in the future).

Comment by Andrew Eisenberg [ 24/May/13 ]

Interesting thing is that it seems that the GPars project triggers the massive jump in ClassNode instances. Full builds of other small and trivial projects keep ClassNode numbers under 6,000 instances.

Comment by Andrew Eisenberg [ 24/May/13 ]

To be clear, it is only a full build that triggers this behavior. Incremental builds do not. Interacting with a groovy file in the editor does not. Both of these actions do cause a minor increase in ClassNodes, but they go away when the project is closed.

What is it about GPars that causes this? Could it be the gradle integration?

Comment by Andrew Eisenberg [ 24/May/13 ]

Just raised GROOVY-6171 for memory issues that are coming from the compiler, not Groovy-Eclipse.

Comment by Andrew Eisenberg [ 27/May/13 ]

Another interesting tidbit. It seems like the JDTClassNodes created by the HighlightingExtenderRegistry and the OutlineExtenderRegistry are backed by an extremely huge Resolver (212 Mb!). These are two groovy classes inside of Groovy-Eclipse that are loaded when a Groovy Editor is opened (or possibly earlier). But, if a groovy editor is opened on startup, these classes will be loaded before any groovy compiler classes are loaded. I don't exactly know why the JDTResolver is so big and more importantly, I'm not sure why a JDTResolver is being used at all.

Rather than delve into the reason why this is happening, I decided to simply convert these classes into Java. The problem has gone away.

Comment by Andrew Eisenberg [ 27/May/13 ]

I am going to convert the remaining groovy files into Java. There are 2: FilePartReader and GroovyShellLaunchDelegate.

Comment by Andrew Eisenberg [ 27/May/13 ]

Just a note that this is not related to the original point of this issue. However, it does significantly reduce memory usage.

Comment by Andrew Eisenberg [ 31/May/13 ]

The main problem that I am seeing here is not the massive number of ClassNodes being generated, but rather that there are some massive ClassNodes. Raised GROOVY-6184 to fix this in the compiler. Already fixed in greclipse 2.1.x, 2.0.x, and 1.8.x.

Problem is that ClassHelper instantiates Enum and Annotation differently from all other ClassNodes. They are lazily initialized, whereas all other class nodes are generated directly from Class objects. This was because historically, groovy had to handle Java 1.4 as well as 1.5. 1.4 support has been dropped, so this distinction is no longer relevant.

Problem is that in greclipse, the first time that an enum or annotation type is declared in source, these ClassNodes in ClassHelper are resolved. They are resolved against the current project and remain fixed that way no matter what happens, even if that project is subsequently deleted from the workspace. This is the cause of the memory leak that I discovered earlier.

This problem also happens in the standalone compiler, but the affects are much less bad.

Comment by Andrew Eisenberg [ 31/May/13 ]

With these changes, memory problems are less severe. So, resolving this issue.





[GRECLIPSE-1630] Unable to open groovy files in Eclipse 3.6 Created: 22/May/13  Updated: 23/May/13  Resolved: 23/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.6.1.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Brian Olson Assignee: Unassigned
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Hello,

I am trying to use GroovyEclipse plugin version 2.6.1 on Eclipse 3.6.3. I am running into a problem where I am unable to open (or create) groovy files.

When I try to create a groovy file I get the following error:

'Building workspace' has encountered a problem.

Errors occurred during the build.

Under the details tab I see:

Errors occurred during the build.
Errors running builder 'Java Builder' on project 'GroovyTest'.
org/codehaus/jdt/groovy/integration/LanguageSupportFactory

After I click 'ok' on this first popup, I see the following error.

Creation of element failed.

org.eclipse.jdt.internal.core.CompilationUnit incompatible with
org.codehaus.jdt.groovy.model.GroovyCompilationUnit

Clicking ok on that window brings me back to the new class dialog.

If I look in my project, I see the class create and I can browse to it in windows explorer and open it in notepad++, however, attempting to open it in eclipse produces the following error:

An error has occurred. See error log for more details.
org.codehaus.groovy.eclipse.refactoring.formatter.GroovyIndentationService

Opening the error log shows me a number of errors, an example stacktrace is

java.lang.NoClassDefFoundError: org.codehaus.groovy.eclipse.refactoring.formatter.GroovyIndentationService
at org.codehaus.groovy.eclipse.editor.GroovyAutoIndentStrategy.<init>(Unknown Source)
at org.codehaus.groovy.eclipse.editor.GroovyConfiguration.getAutoEditStrategies(Unknown Source)
at org.eclipse.jface.text.source.SourceViewer.configure(Unknown Source)
at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.configure(Unknown Source)
at org.eclipse.ui.texteditor.AbstractTextEditor.createPartControl(Unknown Source)
at org.eclipse.ui.texteditor.StatusTextEditor.createPartControl(Unknown Source)
at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.createPartControl(Unknown Source)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.createPartControl(Unknown Source)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.createPartControl(Unknown Source)
at org.codehaus.groovy.eclipse.editor.GroovyEditor.createPartControl(Unknown Source)
at org.eclipse.ui.internal.EditorReference.createPartHelper(Unknown Source)
at org.eclipse.ui.internal.EditorReference.createPart(Unknown Source)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(Unknown Source)
at org.eclipse.ui.internal.EditorReference.getEditor(Unknown Source)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(Unknown Source)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(Unknown Source)
at org.eclipse.ui.internal.WorkbenchPage.access$11(Unknown Source)
at org.eclipse.ui.internal.WorkbenchPage$10.run(Unknown Source)
at org.eclipse.swt.custom.BusyIndicator.showWhile(Unknown Source)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(Unknown Source)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(Unknown Source)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(Unknown Source)
at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(Unknown Source)
at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(Unknown Source)
at org.eclipse.jdt.ui.actions.OpenAction.run(Unknown Source)
at org.eclipse.jdt.ui.actions.OpenAction.run(Unknown Source)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(Unknown Source)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(Unknown Source)
at org.eclipse.jdt.internal.ui.packageview.PackageExplorerActionGroup.handleOpen(Unknown Source)
at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$4.open(Unknown Source)
at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(Unknown Source)
at org.eclipse.jface.viewers.StructuredViewer$2.run(Unknown Source)
at org.eclipse.core.runtime.SafeRunner.run(Unknown Source)
at org.eclipse.ui.internal.JFaceUtil$1.run(Unknown Source)
at org.eclipse.jface.util.SafeRunnable.run(Unknown Source)
at org.eclipse.jface.viewers.StructuredViewer.fireOpen(Unknown Source)
at org.eclipse.jface.viewers.StructuredViewer.handleOpen(Unknown Source)
at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(Unknown Source)
at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(Unknown Source)
at org.eclipse.jface.util.OpenStrategy.access$2(Unknown Source)
at org.eclipse.jface.util.OpenStrategy$1.handleEvent(Unknown Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.ui.internal.Workbench.runEventLoop(Unknown Source)
at org.eclipse.ui.internal.Workbench.runUI(Unknown Source)
at org.eclipse.ui.internal.Workbench.access$4(Unknown Source)
at org.eclipse.ui.internal.Workbench$7.run(Unknown Source)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Unknown Source)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Unknown Source)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(Unknown Source)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(Unknown Source)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Unknown Source)
at org.eclipse.equinox.launcher.Main.basicRun(Unknown Source)
at org.eclipse.equinox.launcher.Main.run(Unknown Source)
at org.eclipse.equinox.launcher.Main.main(Unknown Source)
Caused by: org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: An error occurred while automatically activating bundle org.codehaus.groovy.eclipse.refactoring (1568).
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(Unknown Source)
at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 66 more
Caused by: org.osgi.framework.BundleException: Exception in org.codehaus.groovy.eclipse.refactoring.Activator.start() of bundle org.codehaus.groovy.eclipse.refactoring.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(Unknown Source)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source)
at org.eclipse.osgi.framework.util.SecureAction.start(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(Unknown Source)
... 76 more
Caused by: java.lang.NoClassDefFoundError: org.codehaus.jdt.groovy.integration.LanguageSupport
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassName(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(Unknown Source)
at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.codehaus.groovy.eclipse.refactoring.Activator.start(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Unknown Source)
... 82 more
Caused by: java.lang.ClassNotFoundException: org.codehaus.jdt.groovy.integration.LanguageSupport
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 101 more

And the session information from the error is

eclipse.buildId=unknown
java.fullversion=JRE 1.7.0 IBM J9 2.6 Windows 7 x86-32 20120809_118929 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR2_20120809_0948_B118929
JIT - r11.b01_20120808_24925
GC - R26_Java726_SR2_20120809_0948_B118929
J9CL - 20120809_118929
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -product com.ibm.rational.rad.product.v85.ide
Command-line arguments: -os win32 -ws win32 -arch x86 -product com.ibm.rational.rad.product.v85.ide

I found this issue: http://jira.codehaus.org/browse/GRECLIPSE-1194 that suggests upgrading eclipse. Unfortunately that isn't an option for our company, so we would prefer to find another solution. I tried changing all of the libraries in use for the project to Java 1.6, however, it appears that eclipse itself is still using Java 1.7, so I am uncertain if this might cause the issue.

Any suggestions are appreciated. Thanks!



 Comments   
Comment by Andrew Eisenberg [ 22/May/13 ]

I see that you are using RAD. We've had problems in the past with RAD, since it comes with its own patch to JDT. I'm sorry to say that there's not much we can do unless you upgrade to a newer version of Eclipse.

Comment by Brian Olson [ 23/May/13 ]

I understand. Thank you for your speedy response!

Comment by Brian Olson [ 23/May/13 ]

Turned out to be a RAD version issue. Thanks for your help!





[GRECLIPSE-1629] CLONE - Run as Groovy disappears Created: 17/May/13  Updated: 28/May/13  Resolved: 24/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Christophe Domas Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

Windows XP Eclipse Eurpoa


Number of attachments : 0

 Description   

Initially things work like they should, but after some edit and saves the 'Run as Groovy' option is gone from the run menu and new run configurations result in noclassdef exceptions



 Comments   
Comment by Christophe Domas [ 17/May/13 ]

Sorry, I could not reopen the preceding issue, so I tried to clone but I cannot change details, neither description.

So I have almost the same problem, on imported project I don't have "run as groovy" on groovy script until I modified the script.

to reproduce:

  • I use groovy-eclipse-compiler in my maven 3 project:
                <plugin>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>2.3.2</version>
                    <configuration>
                        <compilerId>groovy-eclipse-compiler</compilerId>
                    </configuration>
                    <dependencies>
                        <dependency>
                            <groupId>org.codehaus.groovy</groupId>
                            <artifactId>groovy-eclipse-compiler</artifactId>
                            <version>2.7.0-01</version>
                        </dependency>
                    </dependencies>
                </plugin>
    
                <!-- to add /src/{main,test}/groovy to classpath -->
                <plugin>
                    <groupId>org.codehaus.groovy</groupId>
                    <artifactId>groovy-eclipse-compiler</artifactId>
                    <version>2.7.0-01</version>
                    <extensions>true</extensions>
                </plugin>
    
  • mvn eclipse:eclipse to build eclipse project conf files
  • import project on eclipse
  • eclipse "Run as" contextual menu shows only "Run configurations"
  • modify the groovy class
  • "Run as groovy" appears

env:

  • eclipse juno SR2 on windows 7 64 bits
  • groovy eclipse plugin: 2.7.2.xx-RELEASE-20121219-0800-e42
Comment by Andrew Eisenberg [ 17/May/13 ]

When you import the project into Eclipse, is it being marked as a groovy project? My guess is no since you didn't specify the proper configuration in the maven-eclipse-plugin. Anyway, this step is not even necessary if you are using m2e and the groovy-eclipse configurator for m2e. So, I'd recommend that you try again and just skip the eclipse:eclipse step.

Comment by Andrew Eisenberg [ 23/May/13 ]

Any update here?

Comment by Christophe Domas [ 24/May/13 ]

Hello. Sorry for late response.
The imported project is marked as a groovy project (icon, groovy entry in contextual menu).
I'm actually not using m2e (try to keep mu eclipse as light as possible).

Comment by Andrew Eisenberg [ 24/May/13 ]
  • Are your groovy files in a source folder?
  • Do your source folders exclude groovy files (running mvn eclipse:eclipse will sometimes do that). To check go to Project > Properties -> Java Build Path> Source. Select and expand the source folder containing your groovy code. And make sure that Included is all and Excluded is none.
Comment by Christophe Domas [ 24/May/13 ]
  • after mvn eclipse:eclipse + import project, the only included filter is **/*.java
  • groovy files are in a src/main/groovy folder that is considered by eclipse as a source folder
  • if I add **/*.groovy the "Run as->groovy" appears

So this workaround works. The other one is to modify the file but in this case, the **/*.groovy filter is not in included section.

Comment by Andrew Eisenberg [ 24/May/13 ]

If you want to avoid this problem in the future, you can use m2e and the groovy-eclipse configurator for m2e.

Comment by Christophe Domas [ 28/May/13 ]

Ok, thanks.
I think I'm not alone in this case, so maybe you should update (or ask maintener to update) this page: http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven





[GRECLIPSE-1628] Can't Open Declaration For Anonymous Inner Class Parent Class/Interface Created: 15/May/13  Updated: 23/May/13  Resolved: 23/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Search
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Jeff Brown Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Originally reported here: https://issuetracker.springsource.com/browse/STS-3374

When I Cmd+click on a class name normally that will Open Declaration for that type. That doesn't appear to be working for the parent of an anonymous inner type. For code like that shown below I cannot Cmd+click on Comparable. When I hover I don't get the underlined name that suggests that Comparable can be clicked and Cmd+clicking it doesn't do anything apparent.

someScript.groovy
obj = new Comparable() {
    int compareTo(other) {
        42
    }    
}


 Comments   
Comment by Andrew Eisenberg [ 17/May/13 ]

There's no way to fix this bug without fixing a host of other issues with anonymous inner classes. So, I may as well address them all here.

Some of the problems:

  • navigation (the original subject of this bug report)
  • content assist will not recognize inner type members
  • Structure is not correct
  • The anon inner type is being shown as a member of the containing type, not as a member of the method/field that declares it
  • anon inner types that implement an interface are incorrectly showing that the interface is the super class (not the super-interface).
  • anon inner type name is shown to be 1 (or greater, using the internal type name) rather than using the Eclipse heuristic of something like {{ new Comparable() {...} }}.

Some of these issues already have a jira associated with them, but not worth finding them all now. I'll fix all or most of these problems first and then clean up the issue tracker.

Comment by Andrew Eisenberg [ 20/May/13 ]

Most of the way there now. Navigation, searching and content assist are working. Naming in the outline view works as expected.

Two more pieces I need to sort out is how to do proper ordering in the outline view. First, the anon class is seen as a child of the enclosing type, not the enclosing method. I may just punt on this since the current java model infrastructure mapping is not set up to handle types being declared inside of methods.

Second is something a bit more tricky, but needs to be fixed. There are currently duplicate type errors coming from JDT. This is because the anon type is not being properly resolved by the compiler. It is being resovled with the name of the enclosing type, but is should be resolved with a synthetic name like this: EnclosingTypeName$1. I will need to build up some JDT infrastructure to mimic this resolve. It will be a bit tricky.

Comment by Andrew Eisenberg [ 22/May/13 ]

Committed a bunch of work for this. Support is not complete, but significant progress has been made. Anon types now appear under the proper method declarations. Navigation works to their declarations. Mark occurrences and searching works.

Known limitations so far:

  1. Anon classes declared as a field initializer not supported yet. They still appear separately and with a number for a name. There is a groovy compiler limitation in that there is no way to track the initializer back to the field that declares it.
  2. Only one anon type per method supported. All but the first will be ignored for now.
  3. Also, need to beef up the tests in this area a bit.

Pushing the fix, but more work to be done before this can be called complete.

Comment by Andrew Eisenberg [ 23/May/13 ]

Fixed 2 and 3. #1 is not something that will be easy to fix without more information in the AST. Will raise a new bug for this.

Comment by Andrew Eisenberg [ 23/May/13 ]

And most importantly, the original part of this bug report is fixed as well. You can now navigate to the super definition of an anon type.





[GRECLIPSE-1624] CompilerUtils.getActiveVersion doesn't do what one would expect Created: 03/May/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Based on the name one would expect this method to return the actual version of Groovy that is used/active in the workspace.

But it instead returns a specific version only if it was explicitly specified. Otherwise it will return 'Unspecified'.



 Comments   
Comment by Andrew Eisenberg [ 03/May/13 ]

This issue is the reason why you were seeing some test failures on Groovy 1.8 with the STCTypeLookup and NoClassDefError's. The STCLookup is disabled if the CompilerUtils.getActiveGroovyVersion() is set to 1,8 or less. However, if unspecified, then the STCLookup is still enabled.

Comment by Andrew Eisenberg [ 03/May/13 ]

Proper solution is to change the semantics of CompilerUtils.getActiveVersion and also add a CompilerUtils.getSpecifiedVersion.

Comment by Andrew Eisenberg [ 04/May/13 ]

Changed logic of getActiveSpecifiedVerion so that it always returns the active bundle. It will only return UNSPECIFIED if there are no groovy bundles installed at all (which is indicative of a much larger problem).

Also, chagned the logic of STCTypeLookup so that it looks at the OSGi version, and not the specified version.





[GRECLIPSE-1623] enclosingCall pointcut not matching on all calls Created: 02/May/13  Updated: 02/May/13  Resolved: 02/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Given this DSLD script:

contribute(bind( x: enclosingCall())) {
	x.each { 
		property name: it.methodAsString + "XXX", type: Long
	}
}

and this script:

bar {
	foo {
		 fooXXX
		 barXXX      
	}
}

I would expect both fooXxX and barXXX to be resolved, but only fooXXX is.



 Comments   
Comment by Andrew Eisenberg [ 02/May/13 ]

Fixed with regression tests. Also, ensuring that multiple nested calls with the same name will be grabbed and that order is preserved. Eg- here:

foo {
	foo {
		 fooXXX
		 barXXX      
	}
}

Should keep track of both {{foo}}s





[GRECLIPSE-1622] Fix error marker source positions Created: 26/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The groovy compiler likes to place error markers that are 1 char long for unknown types. Groovy-Eclipse just propagates this marker to the editor. But really, we should be expanding the error marker to cover the entire token.



 Comments   
Comment by Andrew Eisenberg [ 26/Apr/13 ]

I have fixed quite a few marker locations. Now, variable and field declarations have proper underlining. I did some extra work to ensure that array types are correct.

There will be more situations and I will fix them as I notice them.





[GRECLIPSE-1621] global_dsld_support should not need to be there if empty Created: 25/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: rupert thurner Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Number of attachments : 0

 Description   

in corporate environments, user.home is not always available and writable.

greclipse does not work without this, and gives an error:
The container 'Groovy DSL Support' references non existing library 'M:\.groovy\greclipse\global_dsld_support'.

it would be nice if greclipse would not fail because an empty folder is not there.



 Comments   
Comment by Andrew Eisenberg [ 25/Apr/13 ]

This makes sense. I will take a look.

Comment by Andrew Eisenberg [ 25/Apr/13 ]

Pushed a fix. Now, the first time that any container is initialized, groovy-eclipse will look for the global dsld folder. It will try to create if it doesn't exist. If it fails to create it, a single warning will be placed in the error log. But, there will be no other notifications besides that.

Snapshot will be available tomorrow. Please let me know if you get a chance to try it.





[GRECLIPSE-1620] Expose most simple refactorings as quickfixes Created: 23/Apr/13  Updated: 06/Mar/14  Resolved: 06/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist, Refactoring
Affects Version/s: 2.7.2.Release
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We should be exposing the more straightforward refactorings as quickfixes:

  1. extract local variable
  2. convert variable to field
  3. extract constant.


 Comments   
Comment by Mauro Molinari [ 06/Mar/14 ]

Hi Alex, I guess the fix version is 2.9.0.RELEASE, isn't it?

Comment by Alex Boyko [ 06/Mar/14 ]

Yep, should be in 2.9.0. Will be available with the GGTS 3.5 RC2 Please try it out and let us know if there are problems.





[GRECLIPSE-1618] Incorrect formatting of empty method Created: 23/Apr/13  Updated: 07/Aug/14  Resolved: 07/Aug/14

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Minor
Reporter: Alex Abdugafarov Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy/Grails Tool Suite

Version: 3.2.0.RELEASE
Build Id: 201303060821


Number of attachments : 0

 Description   

When invoking Format (Ctrl-Shift-F),

def index() {}

becomes

def index() {
    
}

Fomratting it again results in consistent

def index() {
}

Expected result is that

def index() {}

should remain unchanged.
That's annoying when Grails controller have a bunch of such empty dummy-methods.



 Comments   
Comment by Vasiliy Kizhaev [ 21/Jul/14 ]

Although this case is rather controversial, I thought it would be nice if
empty braces would be left where they stay.
So in both cases:

def method() {}

and

def method() {
}

no formatting will be performed.
The fix is implemented and will be applied soon.

Comment by Vasiliy Kizhaev [ 23/Jul/14 ]

The PR is submitted: https://github.com/groovy/groovy-eclipse/pull/73





[GRECLIPSE-1617] Compiler Level Error randomly appearing / disappearing Created: 22/Apr/13  Updated: 29/Apr/13  Resolved: 29/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Project Settings
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

My setup to reproduce this problem looked as follows:

  • GGTS 3.3.0.M1
  • One 'fresh' Grails 2.2.1 project
  • One 'fresh' Grails 2.3.0 project (using buildsnapshot from hudson)

Since both of these projects require a different Groovy Compiler level I would expect that at any time there is always at least one project that should have an compiler level error.

When I perform a 'clean all projects' the errors seem to appear and disappear somewhat randomly.

Sometimes I'd start out with no errors at all. When I 'clean' at the start I briefly see an error then a little later it goes away.

Sometimes the projects end up in the correct state after the build, sometimes they end up with no error markers at all.

This also happens when I switch compiler levels then re-start. There's a build that happens after restart, but project most often do NOT end up in the correct state.



 Comments   
Comment by Andrew Eisenberg [ 29/Apr/13 ]

Fixed now.





[GRECLIPSE-1616] ClassNotFoundException: org.codehaus.groovy.frameworkadapter.util.SpecifiedVersion Created: 19/Apr/13  Updated: 23/Apr/13  Resolved: 19/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Blocker
Reporter: Juraj Misur Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ggts-info.txt    
Number of attachments : 1

 Description   

After updating to latest snapshot
Groovy Compiler 1.8 Feature 2.8.0.xx-20130418-1600-e42
Groovy-Eclipse Feature 2.8.0.xx-20130418-1600-e42
Groovy-Eclipse M2E integration 2.8.0.xx-20130418-1600-e42
I'm receiving this error:

java.lang.NoClassDefFoundError: org/codehaus/groovy/frameworkadapter/util/SpecifiedVersion
	at org.codehaus.groovy.eclipse.core.compiler.CompilerCheckerParticipant.buildFinished(CompilerCheckerParticipant.java:79)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:233)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:726)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Caused by: java.lang.ClassNotFoundException: org.codehaus.groovy.frameworkadapter.util.SpecifiedVersion
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	... 14 more

Workspace is set to 1.8 compiler but I'm getting error on preference page:
An error has occurred when creating this preference page.



 Comments   
Comment by Andrew Eisenberg [ 19/Apr/13 ]

Thanks for the report. Going through a bit of a rough patch with the nightlies. If you need to get out of this state, you can use the following update site:

http://dist.springsource.org/milestone/GRECLIPSE/e4.2/

I expect that things will be more stable by the end of today.

Comment by Andrew Eisenberg [ 19/Apr/13 ]

Snapshot build is in a better state now. Closing this bug. Please report future issues with this on GRECLIPSE-1328.

Comment by Juraj Misur [ 23/Apr/13 ]

Thanks for prompt fix, 19/Apr snapshot works great.





[GRECLIPSE-1614] Do we need to ship groovy and groovy-all jars inside of org.codehaus.groovy? Created: 17/Apr/13  Updated: 23/May/13  Resolved: 23/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

My guess is yes. I looked at this a while ago and came to the conclusion that we need both, but I forgot why. I will reinvestigate and document the reason here.



 Comments   
Comment by Andrew Eisenberg [ 23/May/13 ]

the groovy jars have been removed. Only groovy-all remains.





[GRECLIPSE-1612] if class has method getProperty(), quickfix does not have "Import " entry Created: 16/Apr/13  Updated: 21/Oct/14  Resolved: 21/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: The Alchemist Assignee: Denis Murashev
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If you have a Groovy class with @TypeChecked and an non-imported class:

User user = new User()

...the quickfix will have a "Import com.whatever.User" option.

If, however, the method has a static getProperty() method, you won't:

User.getProperty("some key")

You'll get a "Add inferenting suggestion" option, but no "Import" option.

Note that User is Java code, not Groovy code, if it matters.



 Comments   
Comment by Andrew Eisenberg [ 23/May/13 ]

Can't reproduce this one. Can you attach full code? Preferably a complete project. Also, what version of groovy and greclipse are you using?

Comment by Vasiliy Kizhaev [ 05/Jun/14 ]

Actually, I am able to reproduce, here are the classes:

FooJava.java
package test;

public class FooJava {
	public static String getProperty() {
		return "sad";
	}
}
FooGroovy.groovy
package blah

class FooGroovy {
	def main() {
		FooJava foo = new FooJava() //import option is suggested
		FooJava.getProperty()            //import option not suggested
	}
}

Note, that FooJava entries in FooJava foo = new FooJava() are underlined with red wavy lines, whereas FooJava and getProperty entries in the next line are underlined with solid black lines.

Tried it on Groovy compiler 2.3.1 and Groovy-Eclipse 2.9.0.xx-201405030018-e43j8.

Labeled with "triaged".





[GRECLIPSE-1611] Inconsistency between AnnotationNode.hasSourceRetention() and JDTAnnotationNode.hasSourceRetention() Created: 16/Apr/13  Updated: 16/Apr/13  Resolved: 16/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In groovy-core, AnnotationNode.hasSourceRetnetion() will return true iff the source retention bit is set AND both the runtime and class retention bits are unset.

In groovy-eclipse, JDTAnnotationNode.hasSourceRetnetion() will return true if the source retention bit is set (ie- it does not look at runtime or class retention.

The groovy-core implementation seems odd to me, but groovy-eclipse should be compatible.



 Comments   
Comment by Andrew Eisenberg [ 16/Apr/13 ]

Fix is committed. Will be available in next snapshot build.





[GRECLIPSE-1610] Static type checking problem Created: 12/Apr/13  Updated: 23/May/13  Resolved: 23/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive GroovyBugsEclipseProject.zip    
Number of attachments : 1

 Description   

The attached project shows an exception in the problems view for full compilation.



 Comments   
Comment by Andrew Eisenberg [ 23/May/13 ]

Now working.





[GRECLIPSE-1606] Be more careful about automatically applying compiler levels to groovy projects Created: 04/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Project Settings
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, if a project does not have a groovy compiler setting, one gets added automatically. And that setting is the compiler level setting of the workspace. This is not always correct and users should also be able to have projects opt-out of compiler mismatch checks.

Proposal here is to:

  1. set compiler level based on groovy jars found in classpath
  2. allow for a new "I don't care" compiler level setting, which will turn off compier checks for the project.


 Comments   
Comment by Andrew Eisenberg [ 04/Apr/13 ]

Done.





[GRECLIPSE-1605] Groovy surround with code templates Created: 03/Apr/13  Updated: 03/Apr/13  Resolved: 03/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Quick fix/assist, Refactoring
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

JDT provides code templates for surrounding code statements with code (eg- if statements, while loops, etc).

This does not work in Groovy since the templates are only available if the file can be parsed using a Java parser.

We should ensure that this functionality is available in Groovy and allow it to be customizable like it is in JDT.



 Comments   
Comment by Andrew Eisenberg [ 03/Apr/13 ]

Now available in build snapshot. Using a similar, but separate infrastructure from JDT, templates are now available.





[GRECLIPSE-1604] NullPointerException during eclipse build at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.inferReturnTypeGenerics(StaticTypeCheckingVisitor.java:2406) Created: 16/Jan/13  Updated: 03/Apr/13  Resolved: 03/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Michael Mess Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: eclipse, exception
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse, please see eclipse ticket link for details.


Number of attachments : 0

 Description   

See also eclipse Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=396602

A NullPointerException occurs during build in eclipse.

java.lang.NullPointerException
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.inferReturnTypeGenerics(StaticTypeCheckingVisitor.java:2406)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:1640)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:67)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitReturnStatement(CodeVisitorSupport.java:73)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitReturnStatement(ClassCodeVisitorSupport.java:224)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitReturnStatement(StaticTypeCheckingVisitor.java:1060)
	at org.codehaus.groovy.ast.stmt.ReturnStatement.visit(ReturnStatement.java:47)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitTryCatchFinally(CodeVisitorSupport.java:82)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitTryCatchFinally(ClassCodeVisitorSupport.java:244)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitTryCatchFinally(StaticTypeCheckingVisitor.java:1834)
	at org.codehaus.groovy.ast.stmt.TryCatchStatement.visit(TryCatchStatement.java:42)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1051)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:1252)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:1226)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1163)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:216)
	at org.codehaus.groovy.transform.StaticTypesTransformation.visit(StaticTypesTransformation.java:70)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1188)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:621)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:599)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:576)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1534)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:662)


 Comments   
Comment by Andy Clement [ 17/Jan/13 ]

What version of Groovy Eclipse do you have installed? It may be worth trying a dev build as some generics related changes have been committed since the last full release.

Comment by Jörg Thönnes [ 08/Mar/13 ]

Sorry for replying late. Our current version is that same is in other Eclispe bugs

2.7.1.xx-20120921-2000-e42-RELEASE

But maybe the developer used the previous version:

2.7.0.xx-20120703-1400-e42-RELEASE

We are now in process of upgrading to E 3.8.2 SR2, which also includes the latest 3.7.2 GRECLIPSE.

Will be happy to provide further information if needed.

Comment by Michael Mess [ 08/Mar/13 ]

I have encountered the bug with "Eclipse SDK 3.8.0.v201206081200 (org.eclipse.sdk.ide)".

In the meantime I have upgraded to Eclipse Version: 3.8.1, Build id: M20120914-1540, and I didn't see the issue so far yet.
There is hope that it could be fixed in that version, but as it occured only sporadic, I cannot say sure.

Both versions are shared installations, more detailed information is available on https://bugs.eclipse.org/bugs/show_bug.cgi?id=401271
I am using the same version as Jörg Thönnes.

Comment by Cédric Champeau [ 03/Apr/13 ]

Assigning to Andrew for a last check.

Comment by Andrew Eisenberg [ 03/Apr/13 ]

We have made some large changes to generics handling and STC inside Groovy-Eclipse post 2.7.2. If you are still having trouble, I would highly recommend updating to a nightly version. Instructions here:

http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-DevelopmentBuilds

If this doesn't work for you, please supply some failing test code so that we can reproduce. And, if possible, it would be nice to verify that this works on the command line.

Comment by Jörg Thönnes [ 03/Apr/13 ]

Hello Andrew,

we (Michael, me and other of our team) are already using the development snapshots.
This issue did not reoccur so far.

Feel free to close this ticket.

Cheers, Jörg

Comment by Andrew Eisenberg [ 03/Apr/13 ]

Thanks for getting back to me. I am closing this issue as you requested. Please comment again if you see the exception again.





[GRECLIPSE-1603] NPE at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createClassNode Created: 03/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release, 2.8.0.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Jörg Thönnes Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version: 2.8.0.xx-20130314-1300-e42


Attachments: Text File Eclipse_error.log     Text File ls-l-groovy.txt    
Number of attachments : 2

 Description   

With the Groovy-Eclipse snapshot build version 2.8.0.xx-20130314-1300-e42 the following exception occurs during the
build:

Errors occured during the build.
   Errors running builder 'JavaBuilder' on project 'utils'.
   java.lang.NullPointerException

Looking at the Eclipse error log I see this exception stack trace:

!MESSAGE Error in inferencing engine for CreateReport.groovy
!STACK 0
java.lang.NullPointerException
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createClassNode(JDTResolver.java:558)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createJDTClassNode(JDTResolver.java:448)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.convertToClassNode(JDTResolver.java:436)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.methodBindingToMethodNode(JDTClassNode.java:338)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initializeMembers(JDTClassNode.java:264)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:233)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:157)
	at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1078)
	at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1070)
	at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:1064)
	at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:1004)
	at org.codehaus.groovy.ast.ClassNode.isScript(ClassNode.java:1220)
	at org.codehaus.groovy.eclipse.core.search.FindAllReferencesRequestor.acceptASTNode(FindAllReferencesRequestor.java:81)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.notifyRequestor(TypeInferencingVisitorWithRequestor.java:1984)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitClassReference(TypeInferencingVisitorWithRequestor.java:701)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitImports(TypeInferencingVisitorWithRequestor.java:847)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:314)
	at org.codehaus.groovy.eclipse.search.GroovyOccurrencesFinder.internalFindOccurences(GroovyOccurrencesFinder.java:174)
	at org.codehaus.groovy.eclipse.search.GroovyOccurrencesFinder.getOccurrences(GroovyOccurrencesFinder.java:102)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.updateOccurrenceAnnotations(GroovyEditor.java:1222)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$6.selectionChanged(JavaEditor.java:3380)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:178)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

This exception occurs several times.



 Comments   
Comment by Jörg Thönnes [ 03/Apr/13 ]

Attached Eclipse error log with several similar NPEs.

Comment by Andrew Eisenberg [ 03/Apr/13 ]

Are you sure that the version you quoted is correct? The line numbers are not matching up for me. Since, based on a previous comment you are using nightly builds, can you post the stack trace for that build instead? Also, it would be nice to have some sample code that we can use to reproduce the failure.

Comment by Jörg Thönnes [ 03/Apr/13 ]

I will double-check tomorrow. Normally, all developer use the same shared installation
which should contain the same Groovy plugin version. Actually, I upgraded this developer yesterday to the newest
version. But the version string is from my Eclipse instance. So it may differ which would surprise me though.

Comment by Jörg Thönnes [ 04/Apr/13 ]

Andy, the Eclipse instance of the developer were the stack trace happened has the same version string displayed by
Help / About Eclipse SDK / Codehaus / Groovy-Eclipse plugin.

Actually, I build this Eclipse shared installation on Friday, 15h March 2013 after the JDT patch for the Eclipse
bug 401271: StackOverflowError when searching for a methods references had been consumed and published as
part of a new snapshot build.

So I wonder why your line numbers do not match up. Do I have any chance to double-check this by other means?

W.r.t. an example: It may be difficult to provide one since this is proprietary code. The error seems to be related to
CreateReport.groovy but I am not sure whether attaching just this class would help here.

Comment by Andy Clement [ 04/Apr/13 ]

I double checked on mine. That stack can't be from a recent greclipse, the createClassNode logic was pulled out into a separate class about 4months ago (and that method no longer exists). You could have a look in the plugin folder for your eclipse installation and we can see what versions of the plugins are in there? If I check for the new class that contains the refactored createClassNode code, I see this:

jar -tvf org.eclipse.jdt.groovy.core_2.8.0.xx-20130304-1200-e42.jar | grep Builder
12142 Mon Mar 04 13:01:20 PST 2013 org/codehaus/jdt/groovy/internal/compiler/ast/JDTClassNodeBuilder.class

What version(s) of org.eclipse.jdt.groovy.core do you have?

Comment by Jörg Thönnes [ 08/Apr/13 ]

Hi Andy,

here is the output of the grep on my installation:

jar -tvf org.eclipse.jdt.groovy.core_2.8.0.xx-20130314-1300-e42.jar |grep Builder
12142 Thu Mar 14 13:20:06 CET 2013 org/codehaus/jdt/groovy/internal/compiler/ast/JDTClassNodeBuilder.class

Please note the time "-1300-e42", I do not have any "-1200-e42" version as you quoted.

Besides that I have managed to keep the old 3.7.2 version around:

rw-rr- 1 root root 306819 Mar 8 16:00 org.eclipse.jdt.groovy.core_2.7.2.xx-RELEASE-20121219-0800-e42.jar
rw-rw-r- 1 root root 309960 Mar 15 15:14 org.eclipse.jdt.groovy.core_2.8.0.xx-20130314-1300-e42.jar

So I wonder how this could happen. I just added the development snapshots and upgraded. Should I also remove
the normal release updates?

Comment by Jörg Thönnes [ 08/Apr/13 ]

Attached list of all plugins matching "groovy".

Please see the attached list: Here are many occurances of 2.7.2.

Comment by Andrew Eisenberg [ 08/Apr/13 ]

Things can get complicated with installations if you have multiple instances of Eclipse that you run from a given install directory, they may be using different p2 profiles and will actually be running two different sets of plugins. I'm not sure if that is what you are experiencing. As an experiment, I would suggest moving (not deleting) the 2.7.2.* plugins to a new location and see what Help -> About Eclipse says is the version of Groovy-Eclipse.

Comment by Jörg Thönnes [ 09/Apr/13 ]

In reply to comment #8:
> Things can get complicated with installations if you have multiple instances of
> Eclipse that you run from a given install directory, they may be using different
> p2 profiles and will actually be running two different sets of plugins. I'm not
> sure if that is what you are experiencing.

In the first place, I agree that the current mixture of plugins is not correct.
I definitely have to correct this and will do so this week. And if the reported stack
trace is from an older version (pre-2.8) this ticket can be closed at that point.

With regard to shared installations: They work quite well for us. We create
an Eclipse installation with a set of plugins required by our developers and finally
make this shared installation read-only. Nobody can update it and Eclipse will
create a local $HOME/.eclipse folder to store some information it need as writeable.
Here also some extra plugins could be installed but they are not allowed to change
or even update the shared installation.

The duplicate GRECLIPSE version 2.7.2 and 2.8.0 result from a wrong shared installation
created by me, not from an update triggered by any developer. But I still wonder why
the older version 2.7.2 from the release update site was not removed as I switched to
the snapshot update site with the 2.8 versions. Next time I will explicitely remove the
old GRECLIPSE version before installing a new one.

> As an experiment, I would suggest
> moving (not deleting) the 2.7.2.* plugins to a new location and see what Help ->
> About Eclipse says is the version of Groovy-Eclipse.

It still displays (as expected by me):

Version: 2.8.0.xx-20130314-1300-e42
Groovy version: org.codehaus.groovy

At this very point I would like to close this issue as "Not A Bug" since it is caused by
a mixed-up installation.

Comment by Andrew Eisenberg [ 09/Apr/13 ]

Thanks for the feedback. As requested, I'm closing this issue.

It's not necessarily a problem that you have 2.7.2 and 2.8.0 bundles mixed together. It would be useful to also have a look at your individual plugins, but only do so if you want to investigate further.

My guess is that there might really be a bug in here somewhere. So, if you do see this problem again, please raise a new issue. And to see which version you are really using, go to Help -> About Eclipse -> Installation details -> Plugins. And paste the version for org.eclipse.jdt.groovy.core.





[GRECLIPSE-1602] NPE in "Refresh DSLD scripts" Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 03/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Erik Vonderheid Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Info from error log:

eclipse.buildId=M20130204-1200
java.version=1.7.0_17
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Framework arguments:  -product org.eclipse.epp.package.rcp.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.rcp.product

Error
Wed Apr 03 07:59:52 CEST 2013
An internal error occurred during: "Refresh DSLD scripts".

java.lang.NullPointerException
	at org.eclipse.m2e.jdt.internal.MavenClasspathContainerInitializer.initialize(MavenClasspathContainerInitializer.java:48)
	at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:2851)
	at org.eclipse.jdt.internal.core.JavaModelManager$9.run(JavaModelManager.java:2757)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2797)
	at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1875)
	at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:3128)
	at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2698)
	at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2862)
	at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1967)
	at org.eclipse.jdt.internal.core.JavaProject.getAllPackageFragmentRoots(JavaProject.java:1435)
	at org.eclipse.jdt.internal.core.JavaProject.getAllPackageFragmentRoots(JavaProject.java:1430)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor$1.run(RefreshDSLDJob.java:215)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.getFragmentRoots(RefreshDSLDJob.java:213)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findDSLDsInLibraries(RefreshDSLDJob.java:105)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findFiles(RefreshDSLDJob.java:95)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.refreshProject(RefreshDSLDJob.java:336)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:284)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)


 Comments   
Comment by Andrew Eisenberg [ 03/Apr/13 ]

Does this exception get thrown repeatedly? Or did you just see it once? I think what is happening here is that there is a race condition between m2e and groovy-eclipse. m2e has not yet finished initializing its internal state. This is not a simple problem to fix since there is no easy way to know when m2e has been initialized. I'll do a little searching to see if there's something I can do.

Comment by Andrew Eisenberg [ 03/Apr/13 ]

I found:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=388039
https://bugs.eclipse.org/bugs/show_bug.cgi?id=387080

Looks like the problem is indeed trying to access maven dependencies too early, before the m2e plugin is fully initialized. I don't know if there is an easy way to check if m2e if fully initialized and I am reluctant to add any m2e dependencies to the dsld code since not all users will have m2e installed.

I will follow up with the m2e team and look for a reasonable solution.

Comment by Andrew Eisenberg [ 03/Apr/13 ]

A possible solution is to check for the o.e.m2e.jdt bundle before refreshing dsld scripts and if it exists ensure that it is started before the refresh job starts.

Comment by Andrew Eisenberg [ 03/Apr/13 ]

Pushed a fix as described in the previous comment. I'm pretty sure this should work. I check to see if the m2e.jdt bundle either doesn't exist or is already started. In this case, we initialize all DSLD scripts. Otherwise, I kick off an asynchronous job that starts the bundle and then initializes the scripts.

Please try the latest dev build when you get a chance and let me know if you continue to see the problem. This is hard for me to test since I have not been able to reproduce the error myself.

Comment by Erik Vonderheid [ 04/Apr/13 ]

Sorry for the late reply. I've seen this error only once and as you described it may be a race condition which is hard to reproduce. I will try the latest dev version anyway and come back to you if I notice the same error.





[GRECLIPSE-1600] Extract Constant fails with "Overlapping text edits" Created: 02/Apr/13  Updated: 03/Apr/13  Resolved: 03/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Erik Vonderheid Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive TestProject.zip    
Number of attachments : 1

 Description   

Here are the details from my error log:

eclipse.buildId=M20130204-1200
java.version=1.7.0_17
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Framework arguments:  -product org.eclipse.epp.package.rcp.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.rcp.product

Error
Tue Apr 02 08:19:00 CEST 2013
Overlapping text edits

org.eclipse.text.edits.MalformedTreeException: Overlapping text edits
	at org.eclipse.text.edits.TextEdit$InsertionComparator.compare(TextEdit.java:121)
	at java.util.Collections.indexedBinarySearch(Collections.java:377)
	at java.util.Collections.binarySearch(Collections.java:365)
	at org.eclipse.text.edits.TextEdit.computeInsertionIndex(TextEdit.java:796)
	at org.eclipse.text.edits.TextEdit.internalAdd(TextEdit.java:781)
	at org.eclipse.text.edits.TextEdit.addChild(TextEdit.java:335)
	at org.eclipse.ltk.core.refactoring.TextChange.addEdit(TextChange.java:167)
	at org.codehaus.groovy.eclipse.refactoring.core.extract.ExtractGroovyConstantRefactoring.checkFinalConditions(ExtractGroovyConstantRefactoring.java:205)
	at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85)
	at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121)
	at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:209)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

I've attached a small example project. The relevant class is EV6_2_TC.

Steps to reproduce:

  1. Select e.g. "Text"
  2. Right Click and select Refactor -> Extract Constant...
  3. => An error dialog appears stating "Overlapping text edits"


 Comments   
Comment by Andrew Eisenberg [ 02/Apr/13 ]

Thanks for reporting the problem and for providing a way to reproduce. I'll take a look.

Comment by Andrew Eisenberg [ 02/Apr/13 ]

I've narrowed the problem down to the following construct:

class Y  {
	void x() {
		1 == "Text"
	}
}

Looks like invoking extract constant from the RHS of a binary expression is causing the problem.

Comment by Andrew Eisenberg [ 03/Apr/13 ]

I just pushed a fix for this with regression tests. Will be available after the next snapshot build completes.





[GRECLIPSE-1597] Using @TypeChecked and list splicing results in NPE when compiling Created: 25/Mar/13  Updated: 26/Mar/13  Resolved: 26/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Linas Ablonskis Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 12.04 64bits, OpenJDK, Java 1.7.0_15


Attachments: Text File stack-trace-2.06.txt     Text File stack-trace-2.1.1.txt    
Number of attachments : 2

 Description   

Using @TypeChecked and list splicing crashes compiler, for example:

import groovy.transform.TypeChecked

class ShowBug {
	@TypeChecked public void test() {
		def list = [1, 2, 3];
		def startIndex = 0;
		def endIndex = 2;
		
		//each of these result in compilation error
		def sublist0 = list[startIndex..endIndex];
		def sublist1 = list[startIndex..<endIndex];
		def sublist2 = list[0..2];
		def sublist3 = list[0..<2];
	}
}

The same happens with the latest (at the time of writing) snapshot release using groovy compiler v2.1, but the stack trace is different. I have attached stack traces for compilers v2.06 and v2.1.1.

The example compiles successfully in groovy console v2.1.2.



 Comments   
Comment by Andrew Eisenberg [ 25/Mar/13 ]

Thanks for reporting the bug. We've done some work since the 2.7.2 release to fix some TypeChecked problems. Can you try upgrading to the latest nightly build?

See here:
http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-DevelopmentBuilds

Let me know if this fixes the problem.

Comment by Linas Ablonskis [ 25/Mar/13 ]

Tried the latest development snapshot for Juno. The problem is no longer present.

Comment by Andrew Eisenberg [ 26/Mar/13 ]

Thanks for getting back to me on this. Closing this issue.





[GRECLIPSE-1594] In Greclipse 2.8.0.xx-20130213-1 / Eclipse 3.8.1: "BUG! exception in phase 'semantic analysis'" Created: 14/Mar/13  Updated: 08/May/13  Resolved: 08/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.8.0.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: David Tonhofer Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File Eclipse Dumps.txt     Zip Archive Faulty Project.zip    
Number of attachments : 2

 Description   

While editing code a dump appears on the console (the last actions was fixing synatx errors, then CTRL-O to reformat imports, which is never advisable)

Attached the dumps, but they are not informative.



 Comments   
Comment by David Tonhofer [ 14/Mar/13 ]

Looks like it's an anonymous class implementation that does it. It's in a test case (admittedly difficult to read):

class TestCaseChannelPersistentStore extends TestStarter {

    @Test
    void testRefreshedChannelMap() {
        boolean throwIfNotFound
        Logger logger = LoggerFactory.getLogger("${CLASS}.testRefreshedChannelMap")
        setUpThenRunClosure( {
            //
            // Create records
            //
            ChannelId chanIdAlpha = channelStore.insertNewEmptyRecord(new ChannelName("alpha"))
            ChannelId chanIdBravo = channelStore.insertNewEmptyRecord(new ChannelName("bravo"))
            ChannelId chanIdCharlie = channelStore.insertNewEmptyRecord(new ChannelName("charlie"))
            ChannelId chanIdDelta = channelStore.insertNewEmptyRecord(new ChannelName("delta"))
            ChannelId chanIdEcho = channelStore.insertNewEmptyRecord(new ChannelName("echo"))
            //
            // No active records
            //
            assertTrue("Only active records: there is none", channelStore.readAllRecords(true, null, null, null).isEmpty())
            //
            // Change state of several records
            //
            B: {
                def action = [ (chanIdAlpha) : VersioningState.ACTIVE,
                               (chanIdBravo) : VersioningState.ACTIVE,
                               (chanIdCharlie) : VersioningState.ACTIVE
                     ]
                channelStore.changeStateOfRecords(action, null, null)
            }
            //
            // Build the "RefreshedChannelMap"
            //
            Verifier routingVerifier
            Verifier mungingVerifier
            DeltaSecondsSource deltaSecondsSource = new DeltaSecondsSource() {
                int getRefreshIntervalInSeconds() {
                    return 2
                }
            }            
            RefreshedChannelMap rcmap = new RefreshedChannelMap(channelStore,null,routingVerifier,mungingVerifier)
            ChannelMap chanMap = rcmap.getLatestMap()
            chanMap.getActiveRecord(new ChannelName("alpha"), throwIfNotFound = true)
            chanMap.getActiveRecord(new ChannelName("bravo"), throwIfNotFound = true)
            chanMap.getActiveRecord(new ChannelName("charlie"), throwIfNotFound = true)
        }, DELETE_TABLES_AT_END)
    }
}

If one comments out the "DeltaSecondsSource" definition, things can compile. Commenting it in immediately results in "BUG!"

Tried to define it outside of the closure and outside of the method, same problem.

Comment by Andrew Eisenberg [ 15/Mar/13 ]

Is there any chance that you can send over a project that has this error? I tried reproducing naively from your comment, but can't.

Comment by David Tonhofer [ 19/Mar/13 ]

I will see what I can do. I tried to set up minimal code to reproduce the error and it compiles nicely.

Comment by David Tonhofer [ 20/Mar/13 ]

All right, this should be actually usable. Minimal code!

I have a .groovy file:

TestCaseChannelPersistentStore.groovy
package tests.msgserver_store_channel

import static org.junit.Assert.*

import org.junit.BeforeClass
import org.junit.Test

import com.mplify.msgserver.channel_store_map.RefreshedChannelMap

class TestCaseChannelPersistentStore {

    /**
     * Make bug APPEAR by commenting out the next function, commenting it back in, then CTRL-S to save.
     * Make bug DISAPPEAR by commenting out the single instruction     
     */
    
    @BeforeClass
    public static void setUpDbConnPool() throws Exception {         
        def clazz = TestCaseChannelPersistentStore.class;
    }    

    @Test
    void testRefreshedChannelMap() {
       def x = new DeltaSecondsSource() { public int getRefreshIntervalInSeconds() { return 2 } }       
    }
}

And...

DeltaSecondsSource.java
package tests.msgserver_store_channel;

public interface DeltaSecondsSource {
    
    public int getRefreshIntervalInSeconds();

}

Proceed as shown in the description to make the problem appear!

Comment by Andrew Eisenberg [ 20/Mar/13 ]

Thanks for the sample. Hopefully this is enough to reproduce for me. I'll try this right now.

Comment by Andrew Eisenberg [ 20/Mar/13 ]

Unfortunately, still working for me. When you separate these two files into their own project, are you still getting the error? I was hoping for a zipped up project that reproduces the error. It's possible that there are other files in the current project that are getting in the way even though they are not directly accessed by the two files. Also, you have import com.mplify.msgserver.channel_store_map.RefreshedChannelMap is that important?

Comment by David Tonhofer [ 20/Mar/13 ]

Hi Andrew

The "import" is a leftover, it should not be important.

I will try with a fresh workspace, and only those two files in a newly created package. We shall see. (I have a board meeting starting "any minute now", so this may take some time).

Best regards

Comment by David Tonhofer [ 21/Mar/13 ]

Tried with a fresh workspace and just the files above ... the error cannot be reproduced.

defeat.jpg

Comment by David Tonhofer [ 21/Mar/13 ]

Ha HA! Perseverance pays off. This one fails. Zipped project file attached.

Comment by Andrew Eisenberg [ 21/Mar/13 ]

This is great! We have been looking for a way to reproduce this bug for a while now (not just you, but other users occasionally hit it). Now that we can reproduce it on our side, we can have a look and finally fix it. Thanks for getting the project together.

Comment by Andy Clement [ 22/Mar/13 ]

Awesome testcase. I distilled it down a little more to remove the junit dependency. The key factors in a testcase for this are:

  • a structural change to a type is made (new method in this case)
  • a reference is being made to something that groovy will try to find as an inner class (TestCaseChannelPersistentStore.class) - it won't find it but it is important to be there
  • an anonymous inner class is being created via 'new <someinterface>'
  • another type depends on the type that was structurally changed (AllTests in this case)

With that pattern the incremental build proceeds as follows:

  • uncomment the code with the .class reference in.
  • we attempt to build the class containing the reference, it doesn't go perfectly because groovy has considered the reference to the interface (DeltaSecondsSource) as a class reference. The file containing the new anonymous type is marked as having an inconsistent hierarchy.
  • when we finish compiling it, we consider the new method a structural change so we do another round of compilation involving that type and any that depend on it
  • we kick off compilation of the dependent type and the groovy type (because it looked like it didn't totally work before) - the incremental build state actually remembers that it didn't totally work before so references into it try to be resolved via source, it is mistakenly not going to look at the binary (groovy did manage to create the binary, but jdt doesnt't realise).
  • On this secondary compile the TestCaseChannelPersistentStore.class reference is found and we look in the source for a TestCaseChannelPersistentStore$class inner class (because we don't realise the binary is there)
  • as we are going from the source for TestCaseChannelPersistentStore we ask the parser to compile it... we are already compiling code so hence the ' Queuing new source whilst already iterating.'. Effectively saying I can't compile this because I'm already doing compilation. Groovy compiles, unlike Java compiles, are done with all the groovy sources at once - it isn't possible to add new ones whilst one is already in progress.

Anyway, long story short. The absolutely correct fix (but not for today) is to sort out groovys problems with considering an interface a class (and thus making the anonymous type look broken). The temporary fix, because the reference it is chasing down (TestCaseChannelPersistentStore$class) doesn't exist anyway is to avoid attempting to queue the groovy source for compilation on secondary compiles.

I added a regression test for the testcase here and it passes with this change in.

Comment by Andy Clement [ 22/Mar/13 ]

Changes pushed. Updated e37/e42/e43 jdt patches. GroovyCompilationUnitScope is the greclipse code that uses the new patches.

Comment by Andrew Eisenberg [ 22/Mar/13 ]

Nice work!

Comment by David Tonhofer [ 22/Mar/13 ]

Glad to have been of some service.

Roger and Out.

Comment by Andy Clement [ 08/May/13 ]

Believe fixed





[GRECLIPSE-1593] Eclipse "Run as Groovy Script..." throws groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.0.4 and you are trying to load version 2.0.0 Created: 13/Mar/13  Updated: 14/Mar/13  Resolved: 13/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.7.1.Release, 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Minor
Reporter: Jörg Thönnes Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Running a Groovy script using Eclipse run methods

  • "Run as / Groovy Console"
  • "Run as / Groovy Script"

aborts with the exception:

Eclipse Console output for CreateOrderReport[GroovyScript]
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.0.4 and you are trying to load version 2.0.0

but "Run as / Java Application" works fine.

References

  • Installed Groovy version in trunk: 2.0.4
  • Groovy version provided by Eclipse shared installation: 2.0.0
  • The Groovy JAR file for 2.0.4 is part of the Eclipse class-path as Ivy dependency:
    • $HOME/.m2/ivy2/cache/org.codehaus.groovy/groovy-all/jars/groovy-all-2.0.4.jar
  • So there could be a conflict with the 2.0.0 version of the Groovy-Eclipse plugin.
  • IDEA uses directly the Groovy version from the class-path.
  • With the new Groovy plugin 2.7.2 the error message changes to:
    Eclipse Consolve view
    Caught: java.lang.ExceptionInInitializerError
    java.lang.ExceptionInInitializerError
    Caused by: groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.0.4 and you are trying to load version 2.0.6
    
    • So the plugin upgraded Groovy to 2.0.6, but are still using 2.0.4.

Workaround:

  • Change the Groovy version in the Eclipse class-path to be the same as in the plugin.


 Comments   
Comment by Andrew Eisenberg [ 13/Mar/13 ]

You are most likely hitting GRECLIPSE-1530. And the root cause is having multiple versions of groovy on your classpath. It may be that you have the groovy jars coming from ivy AND from the Groovy libraries classpath container. Remove the groovy classpath container and things should work fine.

Comment by Jörg Thönnes [ 13/Mar/13 ]

Thanks, Andrew. Seems you are back from vacation

I solved it the other way round: Adapting the imported Ivy version from 2.0.4 to 2.0.6.
But you are correct: Removing the Groovy class-path container is more generic in the way that
later updates to either the Ivy container or the GRECLIPSE plugin would break it again.

Generally asking: This mismatch in the 3rd position of the version number is really an issue to be checked for?

Comment by Andrew Eisenberg [ 13/Mar/13 ]

This is a check that the groovy runtime performs. And this has its roots in extension methods that Groovy introduced in 2.0. And so this is not something that groovy-eclipse can control. The best that we can do is push this to a compile-time check and make the error message more clear. As I describe in GRECLIPSE-1530.

Comment by Andrew Eisenberg [ 13/Mar/13 ]

Resolving as duplicate of GRECLIPSE-1530.

Comment by Jörg Thönnes [ 14/Mar/13 ]

OK, thanks. I am fine with that explanation.

Comment by Jörg Thönnes [ 14/Mar/13 ]

Checked the project buildpath and did not find any evidence of the Groovy class-path container.
Is it to be disabled in the Groovy Compiler Preferences?





[GRECLIPSE-1592] Extract method refactoring does not respect tabs v spaces preference Created: 12/Mar/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Summary says it all.



 Comments   
Comment by Andrew Eisenberg [ 12/Mar/13 ]

Fixed. Looks like we were not initializing the formatter properly. The formatter was trying to use some non-existent Groovy tabs and spaces settings. I changed it to use the proper JDT settings instead.





[GRECLIPSE-1591] GREclipse plugin break Xtend compiler Created: 03/Mar/13  Updated: 29/Apr/13  Resolved: 29/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Yann Le Moigne Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Hi,

Using Juno SR2 with xtend :
Xtend SDK 2.3.1.v201208210947

Since I set up the Groovy plugin for eclipse
Groovy-Eclipse Feature 2.7.2.xx-RELEASE-20121219-0800-e42
(downloaded from http://dist.springsource.org/release/GRECLIPSE/e4.2/)

Xtend compiler start to fail compilation with many :
Couldn't resolve reference to JvmIdentifiableElement '!'
Couldn't resolve reference to JvmIdentifiableElement '+'
etc.

Don't know which plugin is responsable for that, I open a ticket here and one in their bugzilla...



 Comments   
Comment by Yann Le Moigne [ 03/Mar/13 ]

Link to Xtend bugzilla on the topic : https://bugs.eclipse.org/bugs/show_bug.cgi?id=402250

Comment by Andrew Eisenberg [ 03/Mar/13 ]

Thanks for raising an issue on this. Can you attach a stack trace? Go to Window -> Show view -> Other -> Error Log. And attach any relevant entries.

Comment by Yann Le Moigne [ 04/Mar/13 ]

Some precisions :
I have in the classpath, the 'XTend Library' container.

A plugin setup (don't know which one) bring in platform guava 13.0.0, and the 'XTend Library' start to rely on it, causing invalid generated .java files.
I setup my project classpath to bring a guava_10.0.1 before 'XTend Library', and things worked again.

So I setup again 'Groovy Eclipse', and XTend is broken (again).

I have many many time this error in Error Log (with no stacktrace available).

!ENTRY org.apache.log4j 4 0 2013-03-04 09:21:56.761
!MESSAGE org.eclipse.xtext.common.types.access.impl.AbstractClassMirror - resource is empty: java:/Objects/java.lang.String

Comment by Andrew Eisenberg [ 19/Mar/13 ]

I tried to naively reproduce this problem, but can't. Can you attach a failing project and I will debug from there?

Comment by Andrew Eisenberg [ 04/Apr/13 ]

Any update here? I need a way to reproduce.

Comment by Andrew Eisenberg [ 29/Apr/13 ]

Cannot reproduce. Please include more information and I will explore deeper.





[GRECLIPSE-1590] Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener Created: 01/Mar/13  Updated: 23/May/13  Resolved: 23/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GRECLIPSE-1554 Missing DSLD support for AST transfor... Resolved
Number of attachments : 0

 Description   

Originally reported in GRECLIPSE-1554. See attached project for failing test.

ve tried to use @ListenerList in a groovy 1.8 project but greclipse 2.7.2 fails to compile it showing:

Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener
Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener
Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener
Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener
..
//9 times and growing (looks something internal not refreshing a list of methods)

This happens under the following enviroment:

IDE: Groovy/Grails Tool Suite 3.1.0 (based Eclipse 3.8 Juno)
IDE Groovy compiler: 1.8.6.xx-RELEASE-20121219-0800-e42

If I change the compiler to 2.0.6.xx-RELEASE-20121219-0800-e42 everything works perfectly.

Hope it helps.
Ivan



 Comments   
Comment by Andrew Eisenberg [ 23/May/13 ]

Working in groovy 2.0.x and 2.1.x. Will not try to fix for 1.8.x.





[GRECLIPSE-1589] NPE Thrown from CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:383) when refactoring Grails contoller action Created: 01/Mar/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring, Search
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy 2.0, Grails 2.2.1, GGTS 3.2.0.RC2


Attachments: Zip Archive gTunez.zip    
Number of attachments : 1

 Description   

To reproduce the easiest way I found so far is via the Grails regression tests.

Setup GGTS development env as in 'Environment' field of this issue.

Run this test:
org.grails.ide.eclipse.refactoring.test.GrailsActionRenameTest.testPerformRenameMethodRefactoring()

The test will fail, it also leaves behind its test project that can then be used to easily and repeatedly trigger the bug in a Runtime workbench.

To trigger bug in runtime workbench. Start a RTWB on the JUnit workspace left behind by the test.

Navigate to the method 'list' in 'SongController'. From the package explorer view perform a 'rename method' refactoring on this method.
Click 'Preview'. The bug will trigger.

You can then click 'Back' and 'Preview' again to repeatedly trigger the bug.

Stacktrace:

Caused by: java.lang.NullPointerException
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:383)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:219)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1133)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1215)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1347)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:95)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:593)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.findAllDeclarations(RippleMethodFinder2.java:356)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.findAllRippleMethods(RippleMethodFinder2.java:187)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getAllRippleMethods(RippleMethodFinder2.java:168)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getRelatedMethods(RippleMethodFinder2.java:161)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.initializeMethodsToRename(RenameMethodProcessor.java:244)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.doCheckFinalConditions(RenameMethodProcessor.java:370)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.doCheckFinalConditions(RenameVirtualMethodProcessor.java:146)
	at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:48)
	at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:224)
	at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85)
	at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)



 Comments   
Comment by Kris De Volder [ 01/Mar/13 ]

I tried debugging a little and discovered that the 'scope' field that causes the NPE is set to null on this line of code:

CompilationUnitDeclaration [line: 167] - cleanUp(TypeDeclaration)

I put conditional breakpoint there with a condition like this:
type.toString().contains("class SongController")

Seems to be the 2nd time this BP gets hit that is the 'bad' one.

Comment by Kris De Volder [ 04/Mar/13 ]

Attached zipped up Grails test project (minus compiled .class files).

Comment by Andy Clement [ 04/Mar/13 ]

The MatchLocator already has some code in it to deal with delayed cleanup. I just modified one of the other cleanup calls in the same method (locateMatches) to hook into the same delay mechanism and it no longer fails for me (I was using Kris' sample project and renaming list).

Change pushed to the e42 jdt.core.

Comment by Andrew Eisenberg [ 19/Mar/13 ]

Assuming fixed.





[GRECLIPSE-1588] Static Type Checking DSL NPE Created: 20/Feb/13  Updated: 20/Feb/13  Resolved: 20/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
is depended upon by GROOVY-6011 GroovyTypeCheckingExtensionSupport.sa... Closed
Number of attachments : 0

 Description   

With the following snippets in a project:

RobotMove.groovy

package foot


import org.codehaus.groovy.ast.expr.MethodCall
import org.codehaus.groovy.ast.expr.VariableExpression

unresolvedVariable { VariableExpression var ->
    if ('robot' == var.name) {
        def robotClass = context.source.AST.classes.find { it.name == 'Robot' }
        storeType(var, robotClass)
        handled = true
    }
}

afterMethodCall { MethodCall mc ->
 def method = getTargetMethod(mc)
 if (mc.objectExpression.name == 'robot' && method.name == 'move') {
  def args = getArguments(mc)
  if (args && isConstantExpression(args[0]) && args[0].value instanceof String) {
   def content = args[0].text
   if (!(content in ['left', 'right', 'backward', 'forward'])) {
    addStaticTypeError("'${content}' is not a valid direction", args[0])
   }
  }
  }
}

RobotScript.groovy

package foot

import groovy.transform.TypeChecked

class Robot {
    void move(String dist) { println "Moved $dist" }
}
 
robot = new Robot()

@TypeChecked(extensions = 'foot/RobotMove.groovy')
void operate() {
robot.move"left"
}
java.lang.NullPointerException: Cannot get property 'name' on null object
 at org.codehaus.groovy.runtime.NullObject.getProperty(NullObject.java:56)
 at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:169)
 at org.codehaus.groovy.runtime.callsite.NullCallSite.getProperty(NullCallSite.java:44)
 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227)
 at foot.Script1$_run_closure2.doCall(Script1.groovy:17)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
 at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
 at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
 at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
 at groovy.lang.Closure.call(Closure.java:411)
 at org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.safeCall(GroovyTypeCheckingExtensionSupport.java:266)
 at org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.afterMethodCall(GroovyTypeCheckingExtensionSupport.java:288)
 at org.codehaus.groovy.transform.stc.DefaultTypeCheckingExtension.afterMethodCall(DefaultTypeCheckingExtension.java:124)
 at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2090)
 at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:64)
 at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:70)
 at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
 at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
 at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:36)
 at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
 at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
 at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
 at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
 at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1290)
 at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
 at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:1554)
 at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:1527)
 at org.codehaus.groovy.transform.StaticTypesTransformation.visit(StaticTypesTransformation.java:66)
 at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
 at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
 at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1200)
 at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:632)
 at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:610)
 at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:587)
 at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
 at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1555)
 at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1233)
 at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:712)
 at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1181)
 at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:807)
 at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:544)
 at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
 at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:537)
 at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:480)
 at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
 at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
 at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170)
 at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)


 Comments   
Comment by Andrew Eisenberg [ 20/Feb/13 ]

Turns out that the script above is expected to fail. This is because the it.name is expecting a qualified name (notice that my scripts above are placed in a non-default package). It's unfortunate that a bad script will propagate into the compiler failing. I tried running this on the command line and I get:

Cannot get property 'name' on null object

Something obtuse, but less ugly than what happens in Eclipse. The entire compilation fails and there is no explanation other than the message. We really should be able to recover from this error.

Comment by Andrew Eisenberg [ 20/Feb/13 ]

Well, I can add a better catch block to org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.safeCall(Closure, Object...) and now the error comes out as a compilation problem, rather than an exception in the error log.

Seems like a reasonable fix for me. Will reaise a Groovy issue since seems like they should do the same.

Comment by Andrew Eisenberg [ 20/Feb/13 ]

Fixing this with better error handling as described above.





[GRECLIPSE-1587]  Error in JDT Core during reconcile Created: 19/Feb/13  Updated: 20/Feb/13  Resolved: 19/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Anuja Gote Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7.


Number of attachments : 0

 Description   

This jira has been raised in response to Bug 401042 eclipse bugs from bugzilla.
There is no file in particular that causes this error. If that file is removed the error flows to the next file. the file shows an error for the package statement and says that
"java.lang.Object cannot be resolved. It is indirectly being referenced from required .class files"

Also the exact groovy-eclipse version is : 2.7.2.xx-RELEASE-20121219-0800-e42

stack trace:

Java Model Exception: java.lang.NullPointerException
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:253)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:275)
	at org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:80)
	at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:435)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
	at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:104)
	at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
	at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
Caused by: java.lang.NullPointerException
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.ensureMembersInitialized(JDTAnnotationNode.java:143)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.getMember(JDTAnnotationNode.java:67)
	at org.codehaus.groovy.vmplugin.v5.Java5.configureAnnotationFromDefinition(Java5.java:221)
	at org.codehaus.groovy.vmplugin.v5.Java5.configureAnnotation(Java5.java:241)
	at org.codehaus.groovy.classgen.AnnotationVisitor.visit(AnnotationVisitor.java:81)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotation(ExtendedVerifier.java:154)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotations(ExtendedVerifier.java:115)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitField(ExtendedVerifier.java:64)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1168)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitClass(ExtendedVerifier.java:60)
	at org.codehaus.groovy.control.CompilationUnit$6.call(CompilationUnit.java:832)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1555)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:986)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1025)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:209)
	... 16 more
Caused by: java.lang.NullPointerException
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.ensureMembersInitialized(JDTAnnotationNode.java:143)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.getMember(JDTAnnotationNode.java:67)
	at org.codehaus.groovy.vmplugin.v5.Java5.configureAnnotationFromDefinition(Java5.java:221)
	at org.codehaus.groovy.vmplugin.v5.Java5.configureAnnotation(Java5.java:241)
	at org.codehaus.groovy.classgen.AnnotationVisitor.visit(AnnotationVisitor.java:81)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotation(ExtendedVerifier.java:154)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotations(ExtendedVerifier.java:115)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitField(ExtendedVerifier.java:64)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1168)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitClass(ExtendedVerifier.java:60)
	at org.codehaus.groovy.control.CompilationUnit$6.call(CompilationUnit.java:832)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1555)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:986)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1025)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:209)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:275)
	at org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:80)
	at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:435)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
	at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:104)
	at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
	at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)


 Comments   
Comment by Andrew Eisenberg [ 19/Feb/13 ]

Thanks for the bug report. Which groovy compiler level are you using?

Comment by Andrew Eisenberg [ 19/Feb/13 ]

Ah...looking at the code, I see a path where we can get an NPE. I'll add a proper guard.

Comment by Andrew Eisenberg [ 19/Feb/13 ]

Done. https://github.com/groovy/groovy-eclipse/commit/95f7b046389d1e02e8782b94046c37a7e7882cae

Available in next snapshot build.

Comment by Anuja Gote [ 19/Feb/13 ]

Thank you for the solution Andrew, but how do I fix this in my system?

Comment by Andrew Eisenberg [ 19/Feb/13 ]

Install the update using directions from here:

http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-DevelopmentBuilds

Comment by Anuja Gote [ 20/Feb/13 ]

Issue resolved.
Thanks Andrew.





[GRECLIPSE-1585] Support Groovy 2.1 type checker scripts Created: 14/Feb/13  Updated: 15/Feb/13  Resolved: 15/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Groovy 2.1 introduced type checker scripts. We should support them in Groovy-Eclipse.



 Comments   
Comment by Andrew Eisenberg [ 14/Feb/13 ]

See here for more info: http://docs.codehaus.org/display/GROOVY/Groovy+2.1+release+notes

Comment by Andrew Eisenberg [ 15/Feb/13 ]

Got it in. Working now on some simple cases. I have regression tests. I haven't tested this on complex DSLs, but at least this is a start.

The changes I made for this are:

  1. The transform loader is now a child of the GCL for the project. This way scripts inside of the project can be loaded.
  2. Scripts used to be copied over to output folder after the compile was finished. However, this does not work in the case of STC DSLs since the DSL files need to be available during the compile. So, I changed the ScriptFolderCompilationParticipant to copy scripts over before the compile, not after.

And one more note. If the DSL is a script in the current project, then you must enable script folder support and have that script copied over to the output folder.





[GRECLIPSE-1584] Eclipse gets slow while editing groovy files Created: 12/Feb/13  Updated: 21/Nov/13  Resolved: 04/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: GubeSpam Assignee: Andrew Eisenberg
Resolution: Incomplete  
Labels: eclipse
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, STS 3.0


Attachments: Text File ggts_tdump1.txt     Text File ggts_tdump2.txt     Text File ggts_tdump3.txt     Text File ggts_tdump4.txt     Text File ggts_tdump5.txt     Text File ggts_tdump.txt     Text File .log     File threaddump-1360700639976.tdump     File threaddump-1360700646480.tdump     File threaddump-1360701731625.tdump     File threaddump-1360701738649.tdump     File threaddump-1360701884248.tdump     File threaddump-1360702452846.tdump    
Number of attachments : 13

 Description   

Sometimes, Eclipse gets really slow or even freezes up completely while editing a groovy file (either in the regular editor or in the compare editing when merging in changes from SVN in the Team Synchronization perspective).

Using jvisualvm, I can see the threads "org.eclipse.jdt.internal.ui.text.JavaReconciler" and "main" are trading off blocking each other on an object monitor. I created a few thread dumps during the time while Eclipse was frozen or slow (see attached). It appears that most of the blocking is occurring while waiting on GrailsConsoleErrorPrintStream.



 Comments   
Comment by Andrew Eisenberg [ 12/Feb/13 ]

A few things here:

  1. I am assuming that these are Grails projects because of the references to GrailsConsoleErrorPrintStream. Is this correct?
  2. What version of Groovy-Eclipse are you using (include the timestamp)? (Help -> About GGTS -> Installation details -> Installed software)
  3. What version of Grails-IDE?
  4. What is the underlying version of Eclipse? Is it 3.8 or 4.2? The 4.2 version has known performance degradation when editing. This may not be your problem since it looks to be specific to Groovy/Grails code, but something to consider.
  5. Please attach any relevant errors in your error log.
  6. Lastly, there was this issue on the STS issue tracker regarding something similar: https://issuetracker.springsource.com/browse/STS-2648 It may be that the system properties for avoiding STS-2648 are not set up properly. Open up your GGTS.ini (or eclipse.ini or STS.ini) file and make sure that the system properties from STS-2648 are in your code.
Comment by Andrew Eisenberg [ 20/Mar/13 ]

Any update here?

Comment by Andrew Eisenberg [ 04/Apr/13 ]

No response. Please add more info if you'd like me to look at this more.

Comment by Davide Cavestro [ 21/Nov/13 ]

I'm attaching some thread dumps (ggts_tdump*.txt) and the error log cause I suspect I hit something similar to the situation depicted here.

I was changing the invocation of a certain method to another one for every file invoking it (more or less 20 hits in a dozen of groovy sources). The method usages were listed into the Search view, since I did a Find usages. So I was stepping on every next match and replace the old invocation with the new one. After some changes the editor become quite slow, while there was a Java Search in background. Then the Java Search finished, but the editor was still quite slow (especially when typing something and doing an undo). When I'm waiting for the editor to respond to my inputs, a CPU core is at 100%. In this workspace I have no grails projects opened, but since I had another running eclipse instance with some grails projects I turned it off, but the problem persists.

In the error log there are several messages related to jline (even if I have no grails projects in this workspace).

Now I'm going to restart eclipse and see if the problem is still reproducible. If so, I'll try with the parameter suggested at STS-2648.

I'm using

  • Groovy/Grails Tool Suite Version: 3.4.0.RELEASE Build Id: 201310051614 (Kepler based)
  • Groovy-Eclipse plugin Version: 2.9.0.xx-20130828-1400-e43-RELEASE
  • Grails IDE 3.4.0.201310051518-RELEASE

UPDATE: after a restart the editor works fine, but the error messages in the log reappear. After adding -Djline.terminal=jline.UnsupportedTerminal into GGTS.ini and restarting they went away
UPDATE2: it turned out that - even with the -Djline.terminal=jline.UnsupportedTerminal property - the 1st time I try to find the usages of a method the IDE generates some The type jline.SimpleCompletor cannot be resolved. error messages, even if see no other effects.





[GRECLIPSE-1581] boolean with varargs as parameters cause compilation error Created: 29/Jan/13  Updated: 04/Feb/13  Resolved: 31/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Parser
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Chi Kim Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This only affects eclipse 4.2 release.

public class A {

	public testingBoolean(Object... from) {

		...
	}
	
	public testingBoolean(boolean bool, Object... from) {

		...
	}

}

calling second testingBoolean causes compilation error.

compiling manually via groovyc is successful



 Comments   
Comment by Chi Kim [ 29/Jan/13 ]

Calling the method from groovy class works, but does not work when called from java class.

Comment by Andrew Eisenberg [ 29/Jan/13 ]

Some questions:

  1. What version of groovy-eclipse are you running?
  2. What is the compiler version?
Comment by Andrew Eisenberg [ 31/Jan/13 ]

This may be a JDT bug. I take this Java class:

public class J {
	public static void main(String[] args) {
		new J().testingBoolean(1, 2);
		new J().testingBoolean(false, 1, 2);
	}
	public void testingBoolean(Object... from) {
	}		
	public void testingBoolean(boolean bool, Object... from) {
	}
}

Inside of Eclipse, I get:

The method testingBoolean(Object[]) is ambiguous for the type J

But on the command line the compile is successful. I raised: https://bugs.eclipse.org/bugs/show_bug.cgi?id=399687

Comment by Andrew Eisenberg [ 31/Jan/13 ]

Resolving as won't fix since this is a JDT bug.





[GRECLIPSE-1580] create groovy-eclipse-batch maven artifact for groovy 2.0.6 Created: 28/Jan/13  Updated: 28/Jan/13  Resolved: 28/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Create the groovy-eclipse-batch artifact for our most recent groovy compiler.



 Comments   
Comment by Andrew Eisenberg [ 28/Jan/13 ]

Complete. I re-packaged the groovy-eclipse-batch jar for 2.0.6. Version number is 2.0.6-01.





[GRECLIPSE-1579] NullPointerExceptions in GRECLIPSE Created: 26/Jan/13  Updated: 14/Feb/13  Resolved: 14/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: David Tonhofer Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora Linux 3.6.10-2.fc17.i686


Attachments: XML File MyProfile.formatting.xml     Text File Stack Trace.txt     File Unformattable.groovy    
Number of attachments : 3

 Description   

In


GRECLIPSE Version: 2.7.1.xx-20120921-2000-e42RELEASE

Eclipse SDK Version: 3.8.0 Build id: I20120608-1200


I sometimes get NullPointerExceptions on the console, see attachment.



 Comments   
Comment by Andrew Eisenberg [ 26/Jan/13 ]

This is an error that occurs during reformatting. Can you attach a snippet of code that gives you this error?

Comment by David Tonhofer [ 28/Jan/13 ]

Found one! The error indeed occurs during formatting, which predictably fails.

Comment by David Tonhofer [ 28/Jan/13 ]

Looks like the formatter is distressed by the "return [ pattern, att.value ]"

Comment by Andrew Eisenberg [ 28/Jan/13 ]

Thanks for the sample! With this, it should be easy to fix.

Comment by Andrew Eisenberg [ 28/Jan/13 ]

Unfortunately, I can't reproduce. The Unformattable.groovy file reformats for me with no problem. It does not have the line return [ pattern, att.value ] in it anywhere. When I add that line or use that line in a separate file, I get no problems reformatting it.

Comment by Andrew Eisenberg [ 28/Jan/13 ]

Have you made any changes to your Preferences -> Groovy -> Formatter or your Java fomatter?

Comment by David Tonhofer [ 29/Jan/13 ]

Hi Andrew,

You say:

"It does not have the line return [ pattern, att.value ] in it anywhere"

How is that possible? It clearly does! Check again.

Best regards,

– David

Comment by David Tonhofer [ 29/Jan/13 ]

Hi Andrew,

you write:

"Have you made any changes to your Preferences -> Groovy -> Formatter or your Java formatter?"

I have configured the Java formatter. I attach the "exported" profile, which can be imported using

"Preferences Menu Item" > "Java" > "Code Style" > "Formatter" > "Import Button"

Maybe it will change something.

Best regards,

– David

Comment by Andrew Eisenberg [ 29/Jan/13 ]

How is that possible? It clearly does! Check again.

My bad...it is there. But, I am still not able to reproduce the error. When I was playing around and trying to get the error, I must have deleted the line the first time around. I am about to try again with your formatter settings.

Comment by David Tonhofer [ 14/Feb/13 ]

Possibly fixed in GRECLIPSE 2.7.2.

I updated this morning and in one case an error like this went away. No further errors so far.

Comment by Andrew Eisenberg [ 14/Feb/13 ]

Thanks for following up. I will close this issue, but feel free to comment again if you see the issue come up.





[GRECLIPSE-1575] Disable package inconsistencies for scripts Created: 16/Jan/13  Updated: 21/Jan/13  Resolved: 17/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Groovy files marked as scripts (using the script folder support) should not have their package declaration checked for inconsistency. This makes sense because scripts don't really have the same need for a package declaration that normal files do.



 Comments   
Comment by Andrew Eisenberg [ 17/Jan/13 ]

Committed a fix. See SHA cd0f32d

Fix also includes:

  • Recompile workspace after workspace script folders change
  • Recompile project after project script folders change
  • Cache the script folder checker for each project
Comment by Carl Parisi [ 21/Jan/13 ]

I tried the new code and the package change error is gone, thanks!
However, I am still seeing inconsistent results with my ASTTransform.
I am changing the package name in the transform to a unique name.
I have 2 scripts with the following contents:

class Global

{ int test = 0; }

If I perform a Project->Clean, one of the scripts is flagged with a "Type Global is already defined" error
If I then edit the script and save, the error disappears.

If I then perform a Project->Clean again, the error reappears.

If each script is in its own package, I would not expect to see this error.

the AST transform is defined via the META-INF/services/org.codehaus.groovy.transform.ASTTransformation
It looks like the "groovyTransformsToRunOnReconcile" is not running.

Comment by Andrew Eisenberg [ 21/Jan/13 ]

So, looks like the transform is being properly run on incremental compiles, but not full compiles, or at least something is being done incorrectly on full compiles. I'd have to take a deeper look at this. Can you raise a new issue, since this is not the same problem as before?





[GRECLIPSE-1574] DSLD files defined in Class path container cannot find groovy classes Created: 14/Jan/13  Updated: 14/Jan/13  Resolved: 14/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Carl Parisi Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse Juno on Windows 7


Attachments: Zip Archive groovy.plugin.example.zip    
Number of attachments : 1

 Description   

I have created a plugin that demonstrates the problem.
The attached file has 3 projects.

groovy.plugin.example - plugin project that defines a new "example" nature and defines a container class path that references DSLD
test_example_has_dsld - project that has the "example" nature, and also has the same DSLD in the project
test_example_no_dsld - project that has the "example" nature, but does not have the same DSLD in the project

the "groovy.plugin.example":
defines an "example" nature
defines a classpath container that inludes a DSLD file and a jar
The purpose of the DSLD is to delegate of a groovy script from "groovy.lang.Script" to "example.MyScript"
the class example.MyScript defines a method called "getModel()" which should be available in the groovy script.

test_example_has_dsld - This demonstrates how the DSLD works when it is included in the project source. If you hover over the method "getModel" in test.groovy is presents data from the DSLD

test_example_no_dsld - This demonstrates how the DSLD does not work when it is in the classpath container. If you hover over the method "getModel" in test.groovy it does not find the DSLD data.

I see the following error messages:

org.codehaus.groovy.control.messages.SyntaxErrorMessage@5e900995
org.codehaus.groovy.control.messages.SyntaxErrorMessage@426545b3
org.codehaus.groovy.control.messages.SyntaxErrorMessage@6c30cd3
org.codehaus.groovy.control.messages.SyntaxErrorMessage@6f7ef41c
org.codehaus.groovy.control.messages.SyntaxErrorMessage@77cc9373
/ /my_example.dsld: 8 Groovy:unable to resolve class org.codehaus.groovy.ast.ClassNode
/ /my_example.dsld: 3 Groovy:unable to resolve class org.codehaus.groovy.ast.AnnotationNode
/ /my_example.dsld: 6 Groovy:unable to resolve class org.codehaus.groovy.ast.expr.ListExpression
/ /my_example.dsld: 4 Groovy:unable to resolve class org.codehaus.groovy.ast.expr.ClassExpression
/ /my_example.dsld: 5 Groovy:unable to resolve class org.codehaus.groovy.ast.expr.Expression



 Comments   
Comment by Carl Parisi [ 14/Jan/13 ]

Additional notes:

It is possible to add/remove the nature via project context menu items
Configure->Add Example Nature
Example->Remove Example Nature

Comment by Andrew Eisenberg [ 14/Jan/13 ]

You need to place your dsld file in the dsld folder of your project and add a dsld package statement.

dsld files that come from outside the workspace must be placed in the dsld folder of whatever library they are in.

When I did this, I got your example working.





[GRECLIPSE-1573] Inferencing engine selects wrong method overload Created: 12/Jan/13  Updated: 08/Jul/14  Resolved: 27/Jun/14

Status: Closed
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Peter Niederwieser Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: method-overloading
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS 10.8.2
Eclipse Juno for Java developers 4.2.1


Number of attachments : 0

 Description   

The spock.lang.MockingApi class (which is implemented in Java) declares several overloads for the Mock() method. Among them:

public Object Mock(Map<String, Object> options) 

public <T> T Mock(Class<T> type)

Given the following statement inside a class extending spock.lang.Specification:

def list = Mock(List)

Clicking the Mock method jumps to Mock(Map<String, Object>) instead of Mock(Class<T>), and list} is considered of type {{Object rather than List.



 Comments   
Comment by Vasiliy Kizhaev [ 11/Jun/14 ]

Reopened as a subtask of GRECLIPSE-1702

Comment by Vasiliy Kizhaev [ 24/Jun/14 ]

Pull request for the bug is commited: https://github.com/groovy/groovy-eclipse/pull/56

Comment by Mauro Molinari [ 08/Jul/14 ]

So, is this solved, too? And isn't this very similar to GRECLIPSE-1755?

Comment by Vasiliy Kizhaev [ 08/Jul/14 ]

Yes, this one is solved and nope, it's something else going on there

Comment by Mauro Molinari [ 08/Jul/14 ]

Oh, sorry, I didn't notice it was already marked as solved, this is why I posted my previous comment. Maybe the fix version is 2.9.1 instead?

Comment by Vasiliy Kizhaev [ 08/Jul/14 ]

This was fixed earlier so it might be included to 2.9.0 release, I will find it out later today.





[GRECLIPSE-1572] Use PlatformUI.isWorkbenchRunning() instead of catching NPE Created: 10/Jan/13  Updated: 10/Jan/13  Resolved: 10/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Aurélien Pupier Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

see GroovyPlugin l.207



 Comments   
Comment by Andrew Eisenberg [ 10/Jan/13 ]

Done.

Comment by Aurélien Pupier [ 10/Jan/13 ]

It was fast!
Cool and thanks.





[GRECLIPSE-1571] Support Groovy 2.1 @DelegatesTo annotation Created: 08/Jan/13  Updated: 21/Feb/13  Resolved: 21/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We should support the new Groovy 2.1 @DelegatesTo annotaiton.



 Comments   
Comment by Andrew Eisenberg [ 05/Feb/13 ]

I have a working implementation locally. Need to create some tests.





[GRECLIPSE-1570] Conflicts between greclipse and scala plugin in the same eclipse instance Created: 05/Jan/13  Updated: 10/Jun/13  Resolved: 19/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Carlos Pita Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GRECLIPSE-1641 Greclipse plugin seems to break JDT c... Resolved
Number of attachments : 0

 Description   

Whenever I create a new scala class or object in a java project with scala nature created from scratch to test this issue I get internal errors and stack overflow errors. If I uninstall the greclipse plugin the symptoms disappear.

If you were unable to reproduce the problem in the first attempt please create some groovy class or project and then try again. It should happen sooner than later.

I've tested the combinations A1, A2 and B1 (see below) with a brand new eclipse for java developers indigo flavour.

A. http://dist.springsource.org/release/GRECLIPSE/e3.7/

B. http://dist.springsource.org/milestone/GRECLIPSE/e3.7/

1. http://download.scala-ide.org/sdk/e37/scala29/stable/site/

2. http://download.scala-ide.org/sdk/e37/scala210/dev/site/

Of the three variants tested A2 is the only one which doesn't present the symptoms. Apparently the scala-eclipse team did something in between (voluntarily or not) to fix the issue. Maybe it's related to https://www.assembla.com/spaces/scala-ide/tickets/1000798#/activity/ticket: (notice that there was some relatively recent activity in this ticket).



 Comments   
Comment by Andrew Eisenberg [ 19/Mar/13 ]

Apologies for the delay in getting to this. I installed the latest from http://download.scala-ide.org/sdk/e38/scala210/dev/site/ and am already using the latest nightly groovy-eclipse.

I am resolving this issue, but feel free to re-open or comment if you still see a problem. Also, please include log entries for the problems you are seeing.

Comment by Andrew Eisenberg [ 19/Mar/13 ]

Spoke too soon. I am now seeing an exception on restart. A stackoverflow. I am trying to reproduce in a runtime workbench, but there are operations that causes Eclipse to crash and close itself.

Comment by Andrew Eisenberg [ 19/Mar/13 ]

OK. Now closing for real. The stack overflow is coming from some debug code I added to JDT for GRECLIPSE-1519. Now that the issue is closed, I can safely remove the debug code.

The fact that the debug code triggered a stack overflow implies that there may be something incorrect in the Scala code, because the debug code is quite benign. It is just checking to see if the underlying source buffer is opened. Regardless, the stack overflow is no longer occurring and we can safely close this bug.

I will push and the fix will be available in the next nightly build.





[GRECLIPSE-1569] Allow groovyExtraImports to be configured through Java compiler settings Created: 04/Jan/13  Updated: 31/Jan/13  Resolved: 31/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I'm working on some changes to the way compiler settings are determined such that it will be possible to add Groovy compiler settings to the .settings/org.eclipse.jdt.core.prefs file.

Eg, things like this will work:

org.eclipse.jdt.core.compiler.groovy.groovyExtraImports=some.pack.*
org.eclipse.jdt.core.compiler.groovy.groovyClassLoaderPath=*

will configure the settings on a per-project basis. There is still no UI, but this will make things one step closer to having one.



 Comments   
Comment by Andrew Eisenberg [ 31/Jan/13 ]

Now available.





[GRECLIPSE-1568] groovy import alias support for groovyExtraImports Created: 04/Jan/13  Updated: 04/Jan/13  Resolved: 04/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This issue is tracking the github pull request here:
https://github.com/groovy/groovy-eclipse/pull/3

The goal is to make the groovyExtraImports compiler option support import aliases.



 Comments   
Comment by Andrew Eisenberg [ 04/Jan/13 ]

Pull request has been merged. Need to create some tests in this area and promote it to being "officially supported".





[GRECLIPSE-1567] Plugin won't load from ~/.eclipse Created: 03/Jan/13  Updated: 04/Jan/13  Resolved: 04/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Critical
Reporter: Carlos Pita Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

up-to-date arch linux, tested with eclipse juno classic and for java developers downloaded from eclipse.org


Number of attachments : 0

 Description   

If I recursively set eclipse folder owner to root:root in order to avoid it being written by my user, and then install the groovy plugin so that it's installed at ~/.eclipse, the plugin isn't loaded after restarting eclipse, I mean nothing is working, there is no groovy project button, no groovy preferences, no groovy help, etc.

OTOH, if I remove ~/.eclipse, reinstall eclipse now with write permissions for my user, launch eclipse from scratch, reinstall the groovy plugin and finally restart, then the plugin works as it should.

This is relevant because system package installers will install eclipse without write permission for the user.

Below are some output logs for both cases.

Install under ~/.eclipse ------------------------------

./eclipse -debug
...
Loading extension:
reference:file:../../../home/carlos/.eclipse/org.eclipse.platform_4.2.0_1655951808/plugins/org.codehaus.groovy.frameworkadapter_2.7.2.xx-RELEASE-20121219-0800-e42.jar
  eclipse.properties not found
Framework classpath:
    file:/tmp/eclipse/plugins/org.eclipse.osgi_3.8.1.v20120830-144521.jar
    file:/tmp/eclipse/plugins/
    file:/tmp/eclipse/plugins/../../../home/carlos/.eclipse/org.eclipse.platform_4.2.0_1655951808/plugins/org.codehaus.groovy.frameworkadapter_2.7.2.xx-RELEASE-20121219-0800-e42.jar

ls  ~/.eclipse/org.eclipse.platform_4.2.0_1655951808/plugins/

org.codehaus.groovy_1.7.10.xx-RELEASE-20121219-0800-e42
org.codehaus.groovy_1.8.6.xx-RELEASE-20121219-0800-e42
org.codehaus.groovy.eclipse_2.7.2.xx-RELEASE-20121219-0800-e42
org.codehaus.groovy.eclipse.ant_2.7.2.xx-RELEASE-20121219-0800-e42
org.codehaus.groovy.eclipse.astviews_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.codehaus.groovy.eclipse.codeassist.completion_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.codehaus.groovy.eclipse.codebrowsing_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.codehaus.groovy.eclipse.core_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.codehaus.groovy.eclipse.dsl_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.codehaus.groovy.eclipse.quickfix_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.codehaus.groovy.eclipse.refactoring_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.codehaus.groovy.eclipse.ui_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.codehaus.groovy.frameworkadapter_2.7.2.xx-RELEASE-20121219-0800-e42.jar
org.eclipse.jdt.core_3.8.2.xx-RELEASE-20121219-0800-e42.jar
org.eclipse.jdt.groovy.core_2.7.2.xx-RELEASE-20121219-0800-e42.jar

Install under <eclipse>/plugins ------------------------------

rm -rf ~/.eclipse/

./eclipse -debug
...
Loading extension:
reference:file:org.codehaus.groovy.frameworkadapter_2.7.2.xx-RELEASE-20121219-0800-e42.jar
  eclipse.properties not found
Framework classpath:
    file:/tmp/eclipse/plugins/org.eclipse.osgi_3.8.1.v20120830-144521.jar
    file:/tmp/eclipse/plugins/
    file:/tmp/eclipse/plugins/org.codehaus.groovy.frameworkadapter_2.7.2.xx-RELEASE-20121219-0800-e42.jar

ls /tmp/eclipse/plugins/org.codehaus.groovy*

/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.astviews_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.completion_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.codebrowsing_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.core_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.dsl_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.quickfix_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.refactoring_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.ui_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy.frameworkadapter_2.7.2.xx-RELEASE-20121219-0800-e42.jar
/tmp/eclipse/plugins/org.codehaus.groovy_1.7.10.xx-RELEASE-20121219-0800-e42
/tmp/eclipse/plugins/org.codehaus.groovy_1.8.6.xx-RELEASE-20121219-0800-e42
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse_2.7.2.xx-RELEASE-20121219-0800-e42
/tmp/eclipse/plugins/org.codehaus.groovy.eclipse.ant_2.7.2.xx-RELEASE-20121219-0800-e42



 Comments   
Comment by Andrew Eisenberg [ 03/Jan/13 ]

There is a long standing p2 bug that prevents installing feature patches into shared installs. Groovy-eclipse uses a feature patch to patch the jdt compiler. And a shared install occurs whenever the install directory is read-only.

A good description of this problem is here https://bugs.eclipse.org/bugs/show_bug.cgi?id=395516

Unfortunately, this problem is out of our hands.

Comment by Carlos Pita [ 03/Jan/13 ]

I think this may not be related to the groovy plugin at all.

http://askubuntu.com/questions/186299/eclipse-juno-need-root-access-everytime-i-change-the-configuration

https://bugs.eclipse.org/bugs/show_bug.cgi?id=322158

https://bugs.eclipse.org/bugs/show_bug.cgi?id=297329

I just had a(nother, not the one reported) problem with the plugin, deleted my ~/.eclipse directory in order to start from scratch and wasn't able to reinstall the plugin anymore. But this seems more like a bug in eclipse.

Comment by Carlos Pita [ 03/Jan/13 ]

Ninjaed.

Comment by Carlos Pita [ 03/Jan/13 ]

I understand, maybe you should include a warning in the faq. This is maddening for the unaware. And I guess it must be a typical issue for people installing eclipse from their system package managers.

Comment by Andrew Eisenberg [ 04/Jan/13 ]

Hmmm...we used to have a big disclaimer in the FAQ, but looks like it was removed during a recent reorganization.

Probably the best thing to do would be to add the information back to the FAQ and put it on the main page.

Comment by Carlos Pita [ 04/Jan/13 ]

What's the best workaround? To install eclipse on a user basis or to make a shared version completely writeable I find as extreme solutions. Does eclipse allow to install specific plugins for everyone in a shared installation? Sure it can be done changing write permission before and after the specific plugin installation, but do you know if there is a cleaner way?

Comment by Andrew Eisenberg [ 04/Jan/13 ]

Resolving this bug as won't fix since I can't do much about the underlying issue.

I added the entry back to the FAQ and I also added a warning to the main Groovy-Eclipse page.

Comment by Andrew Eisenberg [ 04/Jan/13 ]

What's the best workaround? To install eclipse on a user basis or to make a shared version completely writeable I find as extreme solutions. Does eclipse allow to install specific plugins for everyone in a shared installation? Sure it can be done changing write permission before and after the specific plugin installation, but do you know if there is a cleaner way?

If there is a shared instance of Eclipse, log in as a user who can write to the shared instance, install groovy-eclispe as that user, then log out. Then Groovy-eclipse will be available for all users. There is no cleaner way AFAIK.





[GRECLIPSE-1566] Easier way to fix compiler version mismatches Created: 31/Dec/12  Updated: 04/Jan/13  Resolved: 04/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When switching between compiler versions, many projects will get a build error on them. We should add an easy way to fix all broken projects in the workspace at once.



 Comments   
Comment by Andrew Eisenberg [ 31/Dec/12 ]

Fixed. Created a new dialog that shows all compiler mismatches and a way to fix them. To access, go to Project -> Groovy -> Fix compiler mismatches.





[GRECLIPSE-1565] Building Grails project in STS post upgrade to 2.7.2 now throws NullPointerException at JDTClassNodeBuilder.toRawType(JDTClassNodeBuilder.java:116) Created: 21/Dec/12  Updated: 24/May/13  Resolved: 07/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Christopher Kwiatkowski Assignee: Andy Clement
Resolution: Fixed  
Labels: eclipse, exception, plugin
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse.buildId=3.1.0.201210061306-RELEASE-e42
java.version=1.7.0_10
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.springsource.sts.ide
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.springsource.sts.ide


Attachments: Text File .log    
Number of attachments : 1

 Description   

Our grails 2.1.1 project will not build now, though the project compiles using the command line "grails compile". The project was building successfully prior to the upgrade to 2.7.2 release. Previously we were using 2.7.1 release.

Internal compiler error: java.lang.NullPointerException at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.toRawType(JDTClassNodeBuilder.java:116) AccountActivationController.groovy /rapcomm/grails-app/controllers/com/rop/account line 0 Java Problem

The error jumps around. If we delete the file that the NPE is thrown on then this error moves to another file in our grails project.

This is a Grails 2.1.1 project using groovy compiler level 1.8.
STS Version Version: 3.1.0.RELEASE Build Id: 201210061306

Stacktrace from STS .log:

!ENTRY org.eclipse.core.resources 4 75 2012-12-20 21:42:44.034
!MESSAGE Errors occurred during the build.
!SUBENTRY 1 org.eclipse.jdt.core 4 75 2012-12-20 21:42:44.034
!MESSAGE Errors running builder 'Java Builder' on project 'rapcomm'.
!STACK 0
java.lang.NullPointerException
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.toRawType(JDTClassNodeBuilder.java:116)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.configureParameterizedType(JDTClassNodeBuilder.java:294)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.configureType(JDTClassNodeBuilder.java:56)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.build(JDTClassNodeBuilder.java:46)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.makeClassNode(JDTClassNode.java:399)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.makeParameter(JDTClassNode.java:379)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.makeParameters(JDTClassNode.java:366)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.methodBindingToMethodNode(JDTClassNode.java:339)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initializeMembers(JDTClassNode.java:256)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:227)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:158)
at org.codehaus.groovy.ast.ClassNode.getDeclaredMethods(ClassNode.java:958)
at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:973)
at org.codehaus.groovy.ast.ClassNode.hasPossibleStaticMethod(ClassNode.java:1417)
at org.codehaus.groovy.control.StaticImportVisitor.findStaticMethod(StaticImportVisitor.java:532)
at org.codehaus.groovy.control.StaticImportVisitor.findStaticMethodImportFromModule(StaticImportVisitor.java:452)
at org.codehaus.groovy.control.StaticImportVisitor.transformMethodCallExpression(StaticImportVisitor.java:242)
at org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:82)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:50)
at org.codehaus.groovy.control.StaticImportVisitor.visitConstructorOrMethod(StaticImportVisitor.java:58)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1181)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
at org.codehaus.groovy.control.StaticImportVisitor.visitClass(StaticImportVisitor.java:52)
at org.codehaus.groovy.control.CompilationUnit$2.call(CompilationUnit.java:686)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1138)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:610)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:588)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:565)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:2015)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:827)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:722)
!SESSION 2012-12-21 09:10:35.400 -----------------------------------------------
eclipse.buildId=3.1.0.201210061306-RELEASE-e42
java.version=1.7.0_10
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.springsource.sts.ide
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.springsource.sts.ide



 Comments   
Comment by Andy Clement [ 21/Dec/12 ]

Are you able to share a project that has this problem in?

Comment by Christopher Kwiatkowski [ 21/Dec/12 ]

I am attempting to re-create the issue in another grails 2.1.1 project. I have not been successful yet. I will post an example project if I can re-create the same error.

Comment by Christopher Kwiatkowski [ 21/Dec/12 ]

I have been unable to re-create the error in a separate project.
We are up against a deadline so we re-installed STS completely and re-imported our projects.
The same project that was throwing errors earlier in 2.7.2 that would not allow the project to build had errors listed in 2.7.1 that showed problems with some Annotations in our tests. @Before @After were shown as errors.
We removed those annotations from our integration tests. Re-tested our application and our tests passed. The project builds in 2.7.1 now and when I have time I will re-visit the issue with 2.7.2.

Comment by Andy Clement [ 21/Dec/12 ]

I'll try out a big grails projects to see if that might trigger this exception.

Comment by Christopher Kwiatkowski [ 21/Dec/12 ]

I am not sure that it will matter, but here are some of our project stats:
app.stats.Controllers.files=148
app.stats.Domain_Classes.files=59
app.stats.Integration_Tests.files=68
app.stats.Services.files=43
app.stats.Unit_Tests.files=125

We are using the following plugins in that application:
plugins.kickstart-with-bootstrap=0.8.6
plugins.mail=1.0.1
plugins.multi-tenant-single-db=0.8.2
plugins.quartz=1.0-RC2
plugins.spring-security-core=1.2.7.3

Comment by Andy Clement [ 02/Jan/13 ]

Just seen on one of our dev machines briefly, but it didn't hang around and has vanished again.

Comment by Andy Clement [ 02/Jan/13 ]

potential fix committed. It definitely won't NPE on that line any more. The NPE was due to attempting to use the lookupenvironment attached to a resolver when doing late (lazy) initialization of a JDTClassNode. If the resolver hasn't been used to resolve anything then no environment is attached. The potential fix is use an environment from elsewhere which should not be null. There are other situations where the resolver environment is being used in JDTClassNodeBuilder but so far no sign of those NPEing. A dev build will be through in a couple of hours - @Christopher: maybe you want to try it out (when you have time)?

Comment by John Wiebe [ 03/Jan/13 ]

I just tried the latest snapshot, and I'm getting a new NPE at a different line ( note, I have a very similiar configuration as in the bug, except I'm using the 1.7 compiler)

java.lang.NullPointerException
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.getUpperbounds(JDTClassNodeBuilder.java:305)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.configureWildcardType(JDTClassNodeBuilder.java:277)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.configureType(JDTClassNodeBuilder.java:62)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.configureTypeArguments(JDTClassNodeBuilder.java:103)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.configureParameterizedType(JDTClassNodeBuilder.java:333)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNodeBuilder.configureType(JDTClassNodeBuilder.java:58)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createJDTClassNode(JDTResolver.java:470)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.convertToClassNode(JDTResolver.java:449)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.methodBindingToMethodNode(JDTClassNode.java:336)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initializeMembers(JDTClassNode.java:256)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:227)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:158)
at org.codehaus.groovy.ast.ClassNode.getInterfaces(ClassNode.java:430)
at org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1053)
at org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1033)
at org.codehaus.groovy.classgen.AsmClassGenerator.doConvertAndCast(AsmClassGenerator.java:3847)
at org.codehaus.groovy.classgen.AsmClassGenerator.doConvertAndCast(AsmClassGenerator.java:3842)
at org.codehaus.groovy.classgen.AsmClassGenerator.storeThisInstanceField(AsmClassGenerator.java:2843)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitFieldExpression(AsmClassGenerator.java:2769)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitAttributeOrProperty(AsmClassGenerator.java:2659)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitPropertyExpression(AsmClassGenerator.java:2734)
at org.codehaus.groovy.classgen.AsmClassGenerator.processClassVariable(AsmClassGenerator.java:2999)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitVariableExpression(AsmClassGenerator.java:2952)
at org.codehaus.groovy.ast.expr.VariableExpression.visit(VariableExpression.java:68)
at org.codehaus.groovy.classgen.AsmClassGenerator.evaluateEqual(AsmClassGenerator.java:4054)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:1488)
at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitAndAutoboxBoolean(AsmClassGenerator.java:4131)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:1469)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:735)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:623)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:598)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:693)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1172)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:274)
at org.codehaus.groovy.control.CompilationUnit$6.call(CompilationUnit.java:866)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1152)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:588)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:566)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:543)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1555)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:662)

Comment by Andy Clement [ 03/Jan/13 ]

Thanks for trying that, the stack trace is invaluable. Hopefully a similar approach to fixing this NPE will also work. Just wish I could recreate this.

Comment by Anthony Nassar [ 03/Jan/13 ]

I've seen every one of these stack traces. If I simply remove the currently offending Groovy source file from the project, an error appears in a different source file, sometimes with one of the other stack traces. I can send my Eclipse .log file; all the stack traces show up there.

Comment by Anthony Nassar [ 03/Jan/13 ]

I'm taking the liberty of attaching the .log file from my Eclipse workspace. You can see additional stack traces, all relating to the same problem.

Comment by Anthony Nassar [ 04/Jan/13 ]

I just installed that latest STS GGTS, and see a new stack trace:

java.lang.NullPointerException
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitIfElse(ClassCodeExpressionTransformer.java:80)
	at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:41)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:50)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructor(ClassCodeVisitorSupport.java:120)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1176)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.control.OptimizerVisitor.visitClass(OptimizerVisitor.java:49)
	at org.codehaus.groovy.control.CompilationUnit$6.call(CompilationUnit.java:794)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1138)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:610)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:588)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:565)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1534)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:662)
Comment by Anthony Nassar [ 04/Jan/13 ]

I don't know how you'd repro this problem, as it doesn't even appear in a consistent way, but I have found a way to make it disappear and reappear for my code. Note that my code actually did have a problem, just not one the the plugin diagnosed correctly. If I compiled my project using an Ant script, I would see errors describing my misuse of the @Immutable annotation:

  [groovyc] C:\git-repos\kea\kea-core\src\main\java\com\...\ImmutableTemporalMetadata.groovy: -1: @Immutable processor doesn't know how to handle field 'endTime' of type 'org.joda.time.DateTime' while compiling class com.palantir.kea.groovy.ImmutableTemporalMetadata.
  [groovyc] @Immutable classes only support properties with effectively immutable types including:
  [groovyc] - Strings, primitive types, wrapper types, BigInteger and BigDecimal, enums
  [groovyc] - other @Immutable classes and known immutables (java.awt.Color, java.net.URI)
  [groovyc] - Cloneable classes, collections, maps and arrays, and other classes with special handling (java.util.Date)
  [groovyc] Other restrictions apply, please see the groovydoc for @Immutable for further details
  [groovyc]  @ line -1, column -1.
  [groovyc] 2 errors

If I remove all such annotation, I'm good to go. The class in question looks like this:

package com....

import groovy.transform.Immutable
import groovy.transform.PackageScope
import groovy.transform.ToString

import org.joda.time.DateTime

import com.....TemporalMetadata;

@Immutable
@PackageScope
@ToString
class ImmutableTemporalMetadata implements TemporalMetadata {
	DateTime startTime
	DateTime endTime
}

Note that the class for the Eclipse plug-in shows an error is an entirely different one, which, perhaps not coincidentally, is the only one to call the constructor for ImmutableTemporalMetadata.

Comment by Christopher Kwiatkowski [ 04/Jan/13 ]

This is likely what was causing the issue for us as well.
We had improperly added Annotations to a couple test classes in a Grails application and once those annotations were removed we no longer see the NullPointerException.
I am going to attempt to re-create the error in a small grails project and send it your way so that you may create some tests around it.

Comment by Andy Clement [ 04/Jan/13 ]

I just put in similar code to address the other possible NPEs in that class. Dev build in an hour or so should contain the changes.

Comment by Andy Clement [ 04/Jan/13 ]

Although the NPEs seem to both stem from trying to compile invalid code, the CodeVisitor one is very different to the JDTClassNodeBuilder ones. I committed a guard for the CodeVisitor one, the underlying Immutable error should now surface in the problems view.

Comment by John Wiebe [ 07/Jan/13 ]

Just tried the latest dev build and I didn't get any Exceptions, Thanks!

Comment by Andy Clement [ 07/Jan/13 ]

thanks for testing that out. I'll close this now and we can reopen if any similar issues are seen.

Comment by Tom Dunstan [ 24/May/13 ]

As another data point, I had this issue and the latest (as of today) 2.8.0 snapshots fixed the problem.





[GRECLIPSE-1563] Problem with interface method implemented by a generic method Created: 20/Dec/12  Updated: 20/Dec/12  Resolved: 20/Dec/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive greclipse-1563.zip    
Number of attachments : 1

 Description   

This looks like a regression in 2.7.2. I am attaching a simple project that reproduces the problem. Open the GClazz groovy class and see that it complains about an unimplemented method. However, this method is indeed implemented by the super class. The super class implements the method with a generic argument.

I have not tried this on the command line version of Groovy.



 Comments   
Comment by Andrew Eisenberg [ 20/Dec/12 ]

Project that shows this problem.

Comment by Andy Clement [ 20/Dec/12 ]

Fix committed - but in doing so it uncovered another generics issue (that isn't visible in this sample project). That generics issue is a groovy bug (I just raised GROOVY-5861) and have had to comment out two of our greclipse tests until it is fixed.

Comment by Andy Clement [ 20/Dec/12 ]

fixed





[GRECLIPSE-1562] IllegalArgmentException when hovering over constructor definition Created: 13/Dec/12  Updated: 14/Feb/13  Resolved: 31/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Hover over the Foo() and you get an exception:

class Foo {
	Foo() {}
}


 Comments   
Comment by Andrew Eisenberg [ 13/Dec/12 ]
java.lang.IllegalArgumentException
	at org.eclipse.jdt.core.Signature.getTypeParameters(Signature.java:2373)
	at org.eclipse.jdt.core.Signature.getTypeParameters(Signature.java:2430)
	at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLabelComposer.appendTypeLabel(JavaElementLabelComposer.java:1010)
	at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLabelComposer.appendElementLabel(JavaElementLabelComposer.java:285)
	at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLinks.getElementLabel(JavaElementLinks.java:559)
	at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLinks.getElementLabel(JavaElementLinks.java:541)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getInfoText(JavadocHover.java:679)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo(JavadocHover.java:612)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.internalGetHoverInfo(JavadocHover.java:565)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo2(JavadocHover.java:557)
	at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:163)
	at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:129)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo2(JavaEditorTextHoverProxy.java:85)
	at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:166)
Comment by Andrew Eisenberg [ 31/Jan/13 ]

Now fixed.

Comment by David Tonhofer [ 14/Feb/13 ]

This error also occurs when one wants to "find references" of a constructor method in which one has just swapped the two parameters.

Fixed, however, in GRECLIPSE 2.8.0





[GRECLIPSE-1560] NPE in Content assist when completing a constructor Created: 12/Dec/12  Updated: 12/Dec/12  Resolved: 12/Dec/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Romain Bioteau Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

in a simple groovy script file type something like :

return new Date| <HIT COMPLETION SHORTCUT>
Select java.sql.Date(long arg0)
NPE is thrown :
java.lang.NullPointerException
at org.codehaus.groovy.eclipse.codeassist.completions.GroovyJavaMethodCompletionProposal.computeReplacementString(GroovyJavaMethodCompletionProposal.java:225)
at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.getReplacementString(LazyJavaCompletionProposal.java:330)
at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:364)
at org.eclipse.jdt.internal.ui.text.java.JavaMethodCompletionProposal.apply(JavaMethodCompletionProposal.java:57)
at org.codehaus.groovy.eclipse.codeassist.completions.GroovyJavaMethodCompletionProposal.apply(GroovyJavaMethodCompletionProposal.java:99)
at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:477)
at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.apply(LazyJavaCompletionProposal.java:488)



 Comments   
Comment by Andrew Eisenberg [ 12/Dec/12 ]

Yes, for some reason, certain constructors are not having their parameter types filled in. I can't isolate why certain ones have parameter types and others don't. I have committed a fix that avoids the problem and fills in with Object parameter types if the correct ones cannot be found.

Comment by Andrew Eisenberg [ 12/Dec/12 ]

Fix is pushed and will be available in in next snapshot.





[GRECLIPSE-1559] Deadlock while editing groovy code in Eclipse Created: 03/Dec/12  Updated: 04/Feb/13  Resolved: 04/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Critical
Reporter: GubeSpam Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 3.0, Windows 7


Attachments: Text File Eclipse deadlock while editing code in groovy editor.txt    
Number of attachments : 1

 Description   

Occasionally Eclipse completely locks up while editing code in the groovy editor, due to a threading deadlock. See attached thread dump.



 Comments   
Comment by Andrew Eisenberg [ 03/Dec/12 ]

Thanks for the bug report and stack traces. Looks like your editor is getting stuck because while in the middle of a reconcile action, there is another operation request to alter the text (in this case, there is a shift() action called).

The first operation first grabs a lock on the groovy ModuleNode and then tries to grab a lock on the document. The second operation does the reverse and each operation is waiting for the lock owned by the other.

I need to find a way to reorder the locks so they are grabbed in the same order for both operations.

Comment by Andrew Eisenberg [ 03/Dec/12 ]

I pushed a change that I think will work. Instead of using synchronized blocks for synchronization of ModuleNodeMapper, greclipse is using {{ReentrantLock}}s. This allows us to check if a lock is grabbed before actually trying to grab it. So, most of the behavior is the same, except that ModuleNode caching will first check to see if the ModuleNodeMapper's lock is grabbed. If it is grabbed by another thread, then we schedule the caching to run later in a separate thread/job. If not grabbed, then we grab and quickly cache it.

The nightly build will run and produce a snapshot. Please try this out and let me know if this fixes the problem. See here for update sites to use to install the nightly snapshot:

http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-DevelopmentBuilds

Comment by Andrew Eisenberg [ 04/Jan/13 ]

Any chance to try this out?

Comment by Andrew Eisenberg [ 31/Jan/13 ]

Any update here?

Comment by GubeSpam [ 02/Feb/13 ]

Sorry, I don't currently have time to download a new version of eclipse, install it and try to reproduce this. It only happens every once in awhile. I reported this error more the good of the community, not because I necessarily needed it myself.

Comment by Andrew Eisenberg [ 02/Feb/13 ]

Thanks for the response. You don't need a new version of Eclipse. All you need to do is paste one of the URLs (appropriate for the version of Eclipse that your STS is built on (likely 3.8 or 4.2).

Go to Help -> Install new software.... In the "work with" section, paste in the appropriate url. Select the new Groovy-Eclipse to upgrade to, click next and follow the instructions.

If you are not able to provide any further feedback, I will close the issue unless someone else reports the same deadlock with a more recent version of Groovy-Eclipse.

Comment by Andrew Eisenberg [ 04/Feb/13 ]

Resolving this issue as fixed. Please comment if you continue to get this problem with the latest snapshot.





[GRECLIPSE-1558] NPE o.c.g.e.GroovyPlugin$JUnitPageListener.pageClosed(): removing JUnit Monospace font listener Created: 29/Nov/12  Updated: 29/Nov/12  Resolved: 29/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Darryl L. Miles Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Juno, Win7, JDK7


Number of attachments : 0

 Description   

Exception seen on startup as in opening a workspace.

"Exception thrown when removing JUnit Monospace font listener"

Version is 2.7.1

eclipse-SDK-M20121121-1200-win32-x86_64\plugins\org.codehaus.groovy.eclipse_2.7.1.xx-20120921-2000-e42RELEASE\about.html

eclipse.buildId=M20121121-1200
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_GB
Command-line arguments: -os win32 -ws win32 -arch x86_64

Error
Fri Nov 30 01:05:56 GMT 2012
Exception thrown when removing JUnit Monospace font listener

java.lang.NullPointerException
at org.codehaus.groovy.eclipse.GroovyPlugin$JUnitPageListener.pageClosed(GroovyPlugin.java:62)
at org.eclipse.ui.internal.PageListenerList$2.run(PageListenerList.java:83)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.runtime.Platform.run(Platform.java:857)
at org.eclipse.ui.internal.PageListenerList.fireEvent(PageListenerList.java:53)
at org.eclipse.ui.internal.PageListenerList.firePageClosed(PageListenerList.java:81)
at org.eclipse.ui.internal.WorkbenchWindow.firePageClosed(WorkbenchWindow.java:991)
at org.eclipse.ui.internal.WorkbenchWindow.busyClose(WorkbenchWindow.java:1176)
at org.eclipse.ui.internal.WorkbenchWindow.access$14(WorkbenchWindow.java:1136)
at org.eclipse.ui.internal.WorkbenchWindow$10.run(WorkbenchWindow.java:1197)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.close(WorkbenchWindow.java:1195)
at org.eclipse.ui.internal.Workbench$16.run(Workbench.java:1106)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.Workbench.busyClose(Workbench.java:1089)
at org.eclipse.ui.internal.Workbench.access$16(Workbench.java:1001)
at org.eclipse.ui.internal.Workbench$17.run(Workbench.java:1182)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.Workbench.close(Workbench.java:1180)
at org.eclipse.ui.internal.Workbench.close(Workbench.java:1153)
at org.eclipse.ui.internal.handlers.QuitHandler.execute(QuitHandler.java:36)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:290)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
at sun.reflect.GeneratedMethodAccessor87.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:231)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:212)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:500)
at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:157)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:587)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:542)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)



 Comments   
Comment by Andrew Eisenberg [ 29/Nov/12 ]

Thanks for the bug report. I am not sure why your IPartListener is coming up null at the point where you are getting the NPE. It doesn't really matter. I added a guard for this location and the exception will no longer be thrown. Will be available in next snapshot build.





[GRECLIPSE-1557] java.lang.invoke.MethodHandleImpl.BindCaller.T is imported by Organize Imports Created: 28/Nov/12  Updated: 04/Dec/12  Resolved: 04/Dec/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Henri Tremblay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Number of attachments : 0

 Description   

Build a project having the latest EasyMock version as a dependency. Create the class below

import org.easymock.EasyMockSupport

class Bar extends EasyMockSupport {

  void myMethod() {
    def s = createMock(String.class);
  }
}

If you do an organize imports on it. This import will appear:

import java.lang.invoke.MethodHandleImpl.BindCaller.T


 Comments   
Comment by Andrew Eisenberg [ 28/Nov/12 ]

This bug was just raised on STS https://issuetracker.springsource.com/browse/STS-3077 I have not been able to reproduce it. The problem you describe here looks the same. I'll see if I can reproduce using your instructions.

Comment by Andrew Eisenberg [ 28/Nov/12 ]

As I feared...I was not able to reproduce. I tried on GGTS using groovy-eclipse 2.7.1 on macos Java 6.

What is the environment that you are using?

Comment by blackdrag blackdrag [ 29/Nov/12 ]

Andrew, java.lang.invoke.MethodHandleImpl is a Java7 class. But java.lang.invoke.MethodHandleImpl.BindCaller is unknown to me. Anyway... if it has anything to do with existing classes, then you will need at least Java7

Comment by Henri Tremblay [ 29/Nov/12 ]

Java 7 is mandatory. You need an existing class named T. As a first try, on can test with

public class T [}

in a package different from your Bar package.

My environment:

  • Java 1.7.0_09
  • Eclipse Juno Service Release 1 (Eclipse Java EE IDE for Web Developers)
  • Groovy plugin 2.7.1.xx-20120921-2000-e42RELEASE
  • Groovy 2.0.5 jar in the project using M2E
  • Reproducted on Windows 7 and OS X Mountain Lion is that's of any use...
Comment by Andrew Eisenberg [ 29/Nov/12 ]

Now I can reproduce. Not only do you have to compile using Java 7, but you also need to launch Eclipse using Java 7. I was not doing that earlier. I tend to use 32 bit eclipses and there's no way to run a 32 Java 7 AFAIK.

I'll need to set up a new dev environment to try this out.

Comment by Henri Tremblay [ 29/Nov/12 ]

Sweet. Well done. I confirm, I'm on Eclipse running with Java 7. The OS, JVM and Eclipse are 32 bits.

Comment by Andrew Eisenberg [ 04/Dec/12 ]

Fixed. The problem is that we have recently changed our internal representation of Generic types to be more aligned with those of Groovy-core. This change manifested itself in organize imports.

Once I was able to recreate the problem, it was easy to fix.





[GRECLIPSE-1556] Support constructor definitions in DSLD syntax Created: 28/Nov/12  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.1.Release
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Andres Almiray Assignee: Unassigned
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GRECLIPSE-1151 Support defining constructor contribu... Open
Number of attachments : 0

 Description   

Please add support for defining constructors. There are some AST transformations that would benefit from this feature (@TupleConstructor, @InheritConstructors, @Canonical).






[GRECLIPSE-1555] Can't define array type in DSLD Created: 27/Nov/12  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andres Almiray Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following code

   method name: "getPropertyChangeListeners",
	  type: "java.beans.PropertyChangeListener[]",

produces this signature in content assist

Object getPropertyChangeListeners()


 Comments   
Comment by Andrew Eisenberg [ 27/Nov/12 ]

Shouldn't be entirely tricky to do.

Comment by Andrew Eisenberg [ 28/Nov/12 ]

Pushed a fix with regression tests. Most cases are working, but some are not. Eg- if you have a dsld property contribution like this:

property name:'foot4', type:'java.util.List<java.lang.String>[]'

ie, using a type parameterized object as an array, type parameters will be lost. This appears to be a limitation of groovy, so there isn't an easy fix for this.

But things like this are working:

property name:'foot4', type:'java.lang.String[][]'

and this:

property name:'foot4', type:'java.util.List<java.lang.String[][]>'

Will be available in next snapshot build.





[GRECLIPSE-1554] Missing DSLD support for AST transformations Created: 27/Nov/12  Updated: 01/Mar/13  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: New Feature Priority: Major
Reporter: Andres Almiray Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File autoExternalize.dsld     File bindable.dsld     Zip Archive GroovyListener.zip     File listenerList.dsld     File logging.dsld     File vetoable.dsld    
Issue Links:
Related
relates to GRECLIPSE-1590 Groovy:Conflict using @groovy.beans.L... Resolved
Number of attachments : 6

 Description   

There are a handful of AST transformations for which no DSLD support is ready. During a recent Hackergarten we put together DSLDs for the following annotations

  • @Log; @Log4j, @Commons, @Slf4j
  • @Bindable, @Vetoable
  • @ListenerList
  • @AutoExternalize


 Comments   
Comment by Andres Almiray [ 27/Nov/12 ]

Attached DSLDs, separated by category

Comment by Andrew Eisenberg [ 28/Nov/12 ]

All of the dslds work as expected. I had to make a few changes to ensure corner cases don't throw exceptions. A few questions and comments:

  1. Missing license statements. I added them
  2. In vetoable and bindable, you add the methods in a separate closure. Is there a reason for this separation? I'd prefer to keep things simpler and not use the closure.
  3. Are there any AST transforms in this list not compatible with groovy 1.8?
  4. I prefer to use class references instead of strings where possible. I am making those changes.
Comment by Andres Almiray [ 28/Nov/12 ]

1. thanks
2. That's because there are 2 pointcuts and we didn't find the syntax for joining them. Either @Bindable/@Vetoable annotates the class or any field with @Bindable/@Vetoable.
3. All of them are specific to Groovy 1.8
4. OK, however keep String literals in the logging xforms as only @Log will work for sure without extra deps in the classpath.

Comment by Andrew Eisenberg [ 28/Nov/12 ]

I only see one pointcut in these dsld files (well, one complex pointcut connected by |).

I simplified the pointcut you have to this:

ontribute(currentType(annotatedBy("groovy.beans.Bindable") |
	       fields(annotatedBy("groovy.beans.Bindable"))))

So, now currentType is only used once. I also made the change to bring the method inside of the contribution block. This still works for me. If you are OK with this, I am just about ready to merge this.

And thanks for pointing out #4. I figured it out the hard way after I tried using class references there.

Comment by Andres Almiray [ 28/Nov/12 ]

Oh I see. I think we had them as separate pointcuts then decided to merge them but left the method definitions outside. It makes more sense to have everything in one place as you suggest.

Comment by Andrew Eisenberg [ 28/Nov/12 ]

Makes sense now. I pushed the contribution. Here is the final commit:

https://github.com/groovy/groovy-eclipse/commit/f5d3f274a72d7b49486f0dc8176356632ff8c36e

I haven't written unit tests for these yet (naughty, naughty), but all is working for me right now.

Comment by Ivan Arrizabalaga Getino [ 01/Mar/13 ]

Hi,
not really sure if it's the same issue or not but it looks related.

I've tried to use @ListenerList in a groovy 1.8 project but greclipse 2.7.2 fails to compile it showing:

Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener
Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener
Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener
Groovy:Conflict using @groovy.beans.ListenerList. Class nortia.GroovyListener already has method addTalkListener
..
//9 times and growing (looks something internal not refreshing a list of methods)

This happens under the following enviroment:

IDE: Groovy/Grails Tool Suite 3.1.0 (based Eclipse 3.8 Juno)
IDE Groovy compiler: 1.8.6.xx-RELEASE-20121219-0800-e42

If I change the compiler to 2.0.6.xx-RELEASE-20121219-0800-e42 everything works perfectly.

Hope it helps.
Ivan

Pd: Attach a mini project to show it.

Comment by Ivan Arrizabalaga Getino [ 01/Mar/13 ]

Minimum project with a @ListenerList annotation.

Comment by Andrew Eisenberg [ 01/Mar/13 ]

Thanks for the bug report, but this is a different issue. I'll raise a new one for you. Currently on vacation, but will look at it when I get back.





[GRECLIPSE-1553] Organize imports error with compile static Created: 25/Nov/12  Updated: 27/Nov/12  Resolved: 27/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Bar.groovy

package example2

class Bar {
	String name
}

Foo.groovy

package example

import groovy.transform.CompileStatic
import example2.Bar

@CompileStatic
class Foo {
  void apply() {
	  new Bar([name: "test"])
  }
}

Perform organize imports on Foo and the Nar import statement goes away.



 Comments   
Comment by Andrew Eisenberg [ 26/Nov/12 ]

The problem here is that a new AST node called org.codehaus.groovy.transform.sc.transformers.ConstructorCallTransformer.MapStyleConstructorCall was introduced post 2.0. This AST node is a sub-class of BytecodeExpression and is not being visited correctly.

All visit operations involving this kind of AST node (including type inferencing) will not work.

Comment by Andrew Eisenberg [ 26/Nov/12 ]

Raised GROOVY-5818 since this is fundamentally a groovy problem that is manifesting itself in groovy-eclipse. Also included in the report is a potential fix.

Comment by Andrew Eisenberg [ 27/Nov/12 ]

Won't be able to look at it today, but will this week.

Comment by Andrew Eisenberg [ 27/Nov/12 ]

Fix is pushed into groovy-eclipse. Getting pull request together for groovy-core.





[GRECLIPSE-1552] Fix Groovy-Eclipse's generics problems Created: 19/Nov/12  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File GenericsBranch-failing UI tests.xml    
Number of attachments : 1

 Description   

Andy is well-under way with a refactoring to ensure that Groovy-Eclipse's generics representation is completely compatible with Groovy-core's representation.

This bug is tracking progress on the refactoring.



 Comments   
Comment by Andrew Eisenberg [ 19/Nov/12 ]

Attaching a test run of the UI tests. Two things are broken here (you can ignore the failing error-logs test). See the failing test cases themselves.

  1. Parameter names of methods from libraries are not being computed properly.
  2. The return type of a method that uses generics is incorrect.
Comment by Andrew Eisenberg [ 19/Mar/13 ]

Refactoring is complete. Tests are passing now.





[GRECLIPSE-1551] Static type checking cannot find an existing method Created: 16/Nov/12  Updated: 11/Mar/13  Resolved: 21/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Linas Ablonskis Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic, breaking
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Mint v12 64bits, OpenJDK, Java 1.7.0_09, Eclipse Indigo SR2


Attachments: File BugClass01.groovy     File BugClass.groovy     File SourceClass01.groovy     File SourceClass.groovy    
Issue Links:
dependent
depends upon GROOVY-6015 Use of Class.forName breaks groovy-Ec... Closed
Number of attachments : 4

 Description   

Groovy (compiler v2.0.4) fails to find a method of the class if the instance of a class is defined and accessed in a certain way. See the attached files for the scenario.

The line
list.size();

in the file BugClass.groovy fails to compile with message
Groovy:[Static type checking] - Cannot find matching method pkg1.ExtendedList#size(). Please check if the declared type is right and if the method exists.

The bug goes away if @TypeChecked is removed from any of the classes.

The bug does not manifest itself on full rebuild of the sources (Clean & Build). It manifests if changes are made (for example add and remove a space symbol) to any of the files, then files are saved and thus a build is triggered.

Eclipse error log shows nothing.

Note that to trigger the error, the classes BugClass and SourceClass + ExtendedList must be in separate packages.

Possibly related to bug GRECLIPSE-1544.



 Comments   
Comment by Andrew Eisenberg [ 16/Nov/12 ]

Thanks for the bug report. I have confirmed that this is a problem. We are looking into CompileStatic issues right now. Hopefully we can have a fix forthis soon.

Comment by Andrew Eisenberg [ 16/Nov/12 ]

A few odd things about this. I added your code to the groovyConsole and I got an exception. See here: GROOVY-5802. So there may be more than just a groovy-eclipse bug happening here.

Comment by Linas Ablonskis [ 18/Feb/13 ]

Found out, that the same kind of problem occurs with methods too. Demonstration in SourceClass01.groovy and BugClass01.groovy. This was tested on Ubuntu Linux 12.04 64bits, OpenJDK, Java 1.7.0_13, Eclipse Juno, Groovy Eclipse 2.8.0, Groovy 2.0.1.

Comment by Andrew Eisenberg [ 18/Feb/13 ]

Thanks for the additional information. I will take a look.

Comment by Andrew Eisenberg [ 20/Feb/13 ]

Doing some digging right now. Made some progress, but nothing definitive and I have to leave now. Some notes:

For an incremental build, stepping through org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBinaryExpression(BinaryExpression) and I would expect that the type of the RHS is used as the type for the LHS, but it is not. Line 2385 and the old value is empty. I would expect that the old value should be an Object class node.

Next, need to see how the correct type gets propagated during a full build.

Comment by Andrew Eisenberg [ 21/Feb/13 ]

The problem is coming from org.codehaus.groovy.transform.stc.SignatureCodecVersion1.doDecode(DataInputStream). The Groovy compiler calls Class.forName(String) on a class. This will not work in Eclipse since we have a different classloader hierarchy. I changed the call to use the current thread's context class loader and now things work for all of incremental, full, and reconcile builds.

I'll also raise a issue on the Groovy project since the fix really should go there.

Comment by Andrew Eisenberg [ 21/Feb/13 ]

See GROOVY-6015.

Comment by Andrew Eisenberg [ 21/Feb/13 ]

Pushed the fix. Will be available in next snapshot build. Let me know if you get a chance to try it out.

Comment by Linas Ablonskis [ 11/Mar/13 ]

Everything is working now, thank you. It also appears to have solved GRECLIPSE-1544.

Comment by Andrew Eisenberg [ 11/Mar/13 ]

Thanks for confirming.





[GRECLIPSE-1550] cannot build grails core - NPE in StaticTypeCheckingVisitor.inferReturnTypeGenerics Created: 13/Nov/12  Updated: 11/Jun/14  Resolved: 11/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I just raised two other issues related to not building grails core. They were with the 2.7.1 release. In testing on master I see this instead (which may be hiding the other issues or may be replacing them). Full st:

java.lang.NullPointerException
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.inferReturnTypeGenerics(StaticTypeCheckingVisitor.java:2806)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:1914)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:205)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:67)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitClosureExpression(CodeVisitorSupport.java:174)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClosureExpression(StaticTypeCheckingVisitor.java:1427)
	at org.codehaus.groovy.ast.expr.ClosureExpression.visit(ClosureExpression.java:43)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBinaryExpression(CodeVisitorSupport.java:144)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBinaryExpression(StaticTypeCheckingVisitor.java:402)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitDeclarationExpression(CodeVisitorSupport.java:245)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitDeclarationExpression(ClassCodeVisitorSupport.java:108)
	at org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:87)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1276)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:1517)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:1491)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(StaticCompilationVisitor.java:117)
	at org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:68)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1542)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:680)


 Comments   
Comment by Lari Hotari [ 25/Mar/13 ]

I'm having this problem in grails-core scb-encoding-support branch.

To reproduce problem:

git clone https://github.com/grails/grails-core.git
git checkout origin/scb-encoding-support
cd grails-core
./gradlew cleanEclipse eclipse

and import all projects in an Eclipse workspace.

grails-aether project gives this error when it tries to compile GrailsConsoleLoggerManager.groovy

Errors running builder 'Java Builder' on project 'grails-aether'.

java.lang.NullPointerException
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.inferReturnTypeGenerics(StaticTypeCheckingVisitor.java:3094)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.inferReturnTypeGenerics(StaticTypeCheckingVisitor.java:3053)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2088)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:220)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.inferComponentType(StaticTypeCheckingVisitor.java:2581)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.getResultType(StaticTypeCheckingVisitor.java:2477)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBinaryExpression(StaticTypeCheckingVisitor.java:424)
	at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallArguments(StaticTypeCheckingVisitor.java:1818)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:1924)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:220)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:64)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBinaryExpression(StaticTypeCheckingVisitor.java:400)
	at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitReturnStatement(CodeVisitorSupport.java:74)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitReturnStatement(ClassCodeVisitorSupport.java:224)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitReturnStatement(StaticTypeCheckingVisitor.java:1334)
	at org.codehaus.groovy.ast.stmt.ReturnStatement.visit(ReturnStatement.java:47)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:36)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1324)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:1588)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.silentlyVisitMethodNode(StaticTypeCheckingVisitor.java:1767)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2070)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:220)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:64)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBooleanExpression(CodeVisitorSupport.java:167)
	at org.codehaus.groovy.ast.expr.BooleanExpression.visit(BooleanExpression.java:40)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitIfElse(StaticTypeCheckingVisitor.java:2241)
	at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:41)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitIfElse(StaticTypeCheckingVisitor.java:2253)
	at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:41)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:36)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1324)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:1588)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:1561)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(StaticCompilationVisitor.java:120)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1177)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:164)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:110)
	at org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:60)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1200)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:632)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:610)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:587)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1555)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:722)

session data:

eclipse.buildId=3.2.0.201303060821-RELEASE-e38
java.version=1.7.0_17
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=fi_FI
Framework arguments:  -showlocation -product org.springsource.sts.ide -groovy.compiler.level 21 -refresh
Command-line arguments:  -os linux -ws gtk -arch x86_64 -showlocation -product org.springsource.sts.ide -data /home/lari/workspace-grails -groovy.compiler.level 21 -refresh

Greclipse version (STS 3.2.0.RELEASE)

org.codehaus.groovy.eclipse.feature (2.8.0.xx-20130304-1200-e42) "Groovy-Eclipse plugin"
org.codehaus.groovy.jdt.patch (2.8.0.xx-20130304-1200-e42) "Groovy-Eclipse plugin"
org.codehaus.groovy18.feature (2.8.0.xx-20130304-1200-e42) "Groovy-Eclipse plugin"
org.codehaus.groovy20.feature (2.8.0.xx-20130304-1200-e42) "Groovy-Eclipse plugin"
org.codehaus.groovy21.feature (2.8.0.xx-20130304-1200-e42) "Groovy-Eclipse plugin"
Comment by Lari Hotari [ 25/Mar/13 ]

NPE in same frame found by google: http://groovy.329449.n5.nabble.com/Log4j-can-t-re-use-superclass-field-tp5713255p5713349.html . I wonder if that's related to this problem.

Comment by Lari Hotari [ 25/Mar/13 ]

StaticTypeCheckingVisitor.java:3094

Comment by Lari Hotari [ 25/Mar/13 ]

This seems to be fixed in Groovy 2.1.2.

Comment by Lari Hotari [ 25/Mar/13 ]

commit was https://github.com/groovy/groovy-core/commit/9251f1b2dd013244165e0ced56035ce744c33602 and issue is GROOVY-6051 .

Comment by Lari Hotari [ 25/Mar/13 ]

Please make Groovy 2.1.1 compiler available to Greclipse. I installed the snapshot build of Greclipse, but it still has 2.1.1 Groovy compiler.

Comment by Andy Clement [ 25/Mar/13 ]

I applied the commits from groovy-6051 (I have not upgraded things to 2.1.2). Please confirm if todays dev builds work for you.

Comment by Lari Hotari [ 26/Mar/13 ]

I can confirm that this problem is fixed in the latest snapshot (Groovy Compiler 2.1 Feature 2.8.0.xx-20130325-0400-e42). Thanks Andy.





[GRECLIPSE-1549] unable to build grails core - 'Cannot find type variable on method' Created: 13/Nov/12  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Might be a dup, I haven't checked:

org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug: Cannot find type variable on method declaring element public abstract T[] toArray(T[]) 
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createClassNode(JDTResolver.java:565)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createJDTClassNode(JDTResolver.java:482)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.convertToClassNode(JDTResolver.java:470)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createClassNodeForArrayBinding(JDTResolver.java:609)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createClassNode(JDTResolver.java:504)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createJDTClassNode(JDTResolver.java:482)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.convertToClassNode(JDTResolver.java:470)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.convertJdtParametersToGroovyParameters(JDTClassNode.java:379)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.methodBindingToMethodNode(JDTClassNode.java:349)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initializeMembers(JDTClassNode.java:274)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:243)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:166)
    at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1095)
    at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1087)
    at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:1081)
    at org.codehaus.groovy.ast.ClassNode.getPlainNodeReference(ClassNode.java:1557)
    at org.eclipse.jdt.groovy.search.VariableScope.cloneInternal(VariableScope.java:687)
    at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:635)
    at org.eclipse.jdt.groovy.search.SimpleTypeLookup.typeFromDeclaration(SimpleTypeLookup.java:490)
    at org.eclipse.jdt.groovy.search.SimpleTypeLookup.findTypeForNameWithKnownObjectExpression(SimpleTypeLookup.java:331)
    at org.eclipse.jdt.groovy.search.SimpleTypeLookup.findType(SimpleTypeLookup.java:213)
    at org.eclipse.jdt.groovy.search.SimpleTypeLookup.lookupType(SimpleTypeLookup.java:80)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.lookupExpressionType(TypeInferencingVisitorWithRequestor.java:1863)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleSimpleExpression(TypeInferencingVisitorWithRequestor.java:1833)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstantExpression(TypeInferencingVisitorWithRequestor.java:1355)
    at org.codehaus.groovy.ast.expr.ConstantExpression.visit(ConstantExpression.java:75)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1518)
    at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBinaryExpression(TypeInferencingVisitorWithRequestor.java:946)
    at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
    at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
    at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
    at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1286)
    at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
    at org.codehaus.groovy.ast.CodeVisitorSupport.visitIfElse(CodeVisitorSupport.java:56)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitIfElse(ClassCodeVisitorSupport.java:219)
    at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:41)
    at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1286)
    at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
    at org.codehaus.groovy.ast.CodeVisitorSupport.visitClosureExpression(CodeVisitorSupport.java:174)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitClosureExpression(TypeInferencingVisitorWithRequestor.java:1221)
    at org.codehaus.groovy.ast.expr.ClosureExpression.visit(ClosureExpression.java:43)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1510)
    at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitField(TypeInferencingVisitorWithRequestor.java:666)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:473)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:374)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:318)
    at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
    at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
    at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
    at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
    at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.initialReconcile(JavaCompositeReconcilingStrategy.java:144)
    at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105)
    at org.eclipse.jdt.internal.ui.text.JavaReconciler.initialProcess(JavaReconciler.java:406)
    at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173)





[GRECLIPSE-1548] unable to build grails core - npe in createPackageDeclaration Created: 13/Nov/12  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
BUG! exception in phase 'semantic analysis' in source unit '/Users/jeff/projects/grails/core/grails-bootstrap/src/main/groovy/grails/util/BuildSettings.groovy' null
    at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:949)
    at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:612)
    at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:561)
    at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
    at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1994)
    at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:980)
    at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1025)
    at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody0(CompilationUnitProblemFinder.java:209)
    at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody1$advice(CompilationUnitProblemFinder.java:244)
    at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:1)
    at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:275)
    at org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:80)
    at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
    at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
    at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
    at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:429)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
    at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
    at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:104)
    at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
    at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
Caused by: java.lang.NullPointerException
    at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.createPackageDeclaration(GroovyCompilationUnitDeclaration.java:384)
    at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.populateCompilationUnitDeclaration(GroovyCompilationUnitDeclaration.java:262)
    at org.codehaus.jdt.groovy.integration.internal.GroovyLanguageSupport.newCompilationUnitDeclaration(GroovyLanguageSupport.java:155)
    at org.codehaus.jdt.groovy.integration.LanguageSupportFactory.newCompilationUnitDeclaration(LanguageSupportFactory.java:73)
    at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:117)
    at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUnit(SourceTypeConverter.java:99)
    at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.accept(CompilationUnitProblemFinder.java:114)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:163)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2554)
    at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitScope.lookupClassNodeForSource(GroovyCompilationUnitScope.java:231)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromCompileUnit(JDTResolver.java:194)
    at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:363)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:389)
    at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:318)
    at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:1016)
    at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:879)
    at org.codehaus.groovy.control.ResolveVisitor.transformMethodCallExpression(ResolveVisitor.java:1226)
    at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:885)
    at org.codehaus.groovy.ast.expr.NotExpression.transformExpression(NotExpression.java:38)
    at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:894)
    at org.codehaus.groovy.control.ResolveVisitor.transformBinaryExpression(ResolveVisitor.java:1178)
    at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:883)
    at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
    at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
    at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
    at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1511)
    at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
    at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitIfElse(ClassCodeExpressionTransformer.java:79)
    at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:41)
    at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
    at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1511)
    at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
    at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:50)
    at org.codehaus.groovy.control.ResolveVisitor.visitConstructorOrMethod(ResolveVisitor.java:225)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
    at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1180)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
    at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1447)
    at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:200)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:755)
    at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:677)
    at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:940)
    ... 25 more


 Comments   
Comment by Andy Clement [ 28/Nov/12 ]

possibly fixed by addressing the other generics issues. No longer seeing this when building grails-core. Let's reopen if it occurs again.





[GRECLIPSE-1547] Can't compile groovy class which is annotated with "net.jcip.annotations.Immutable" Created: 20/Sep/12  Updated: 15/Jan/13  Resolved: 15/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Peti Koch Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7
Groovy Eclipse 2.7.1.xx-20120915
Groovy 2.0.0


Attachments: Zip Archive GroovyEclipseProject.zip    
Number of attachments : 1

 Description   

I have a mixed java/groovy project using the documentary annotations from http://jcip.net/

As soon as I add the net.jcip.annotations.Immutable annotation to a groovy class, the class won't be compiled anymore.

package example

import net.jcip.annotations.Immutable

@Immutable
class ImmutableProblemExample {

	def sayHello(){
		println 'hello groovy world'
	}
}

Eclipse compile errors:

Description	Resource	Path	Location	Type
Duplicate method ImmutableProblemExample() in type ImmutableProblemExample	ImmutableProblemExample.groovy	/Groovy/src/example	line 1	Java Problem
Duplicate method ImmutableProblemExample() in type ImmutableProblemExample	ImmutableProblemExample.groovy	/Groovy/src/example	line 1	Java Problem

I attached a sample project containing the example from above and the jcp-annotations.jar

Maybe the problem is in org.codehaus.groovy.transform.ImmutableASTTransformation:

Line 109:

        // temporarily have weaker check which allows for old Deprecated Annotation
//        if (!MY_TYPE.equals(node.getClassNode())) return;
        if (!node.getClassNode().getName().endsWith(".Immutable")) return;

Best regards & thanks for fixing!
Peti



 Comments   
Comment by Pascal Schumacher [ 08/Nov/12 ]

As a workaround you can use the fully qualified name, e.g.:

package example

@net.jcip.annotations.Immutable
class ImmutableProblemExample {

	def sayHello(){
		println 'hello groovy world'
	}
}
Comment by Paul King [ 09/Nov/12 ]

Can you double check what version of Groovy you are using? e.g.:

println GroovySystem.version

When I run your example using the Groovy/Grails Tool Suite based on Groovy Eclipse 2.7.1.xx-20120921-2000-e42RELEASE with the Groovy 2 feature enabled, it runs fine for me.

Comment by Peti Koch [ 09/Nov/12 ]

println GroovySystem.version -> 2.0.4

At the time I reported this issue, I used 2.0.0, at the moment, I use 2.0.4 and the problem is still the same

As IDE I use:

  • Eclipse Juno SR1
  • Groovy Eclipse 2.7.1.xx-20120921-2000-e42RELEASE

Eclipse project setup:

  • groovy-all-2.0.4.jar is direct as jar in the classpath
  • no usage of Eclipse "Groovy Libraries"

Thanks for analysing.

Comment by Paul King [ 09/Nov/12 ]

Are you in a position to compile from the command line? That would help us understand whether the problem might be due to Groovy or the Eclipse plugin.

For background, ImmutableASTTransformation should not be called at all unless you annotate your class with the groovy.transform.Immutable annotation. In earlier versions of Groovy there was also a groovy.lang.Immutable that was always imported - but should have been resolved after anything you import yourself.

Another workaround would probably be to use 'as' with your import (e.g. import net.jcip.annotations.Immutable as ImmutableMarker or ImmutableJCIP or whatever, and then annotate with @ImmutableMarker or whatever)- but it has no real advantage to what you have already proposed.

Comment by Peti Koch [ 09/Nov/12 ]

Paul, probably this answers your question, too:
I just tried to build the project with Ant and the groovc task -> this works fine.

Seems to be an Eclipse plugin issue.

Comment by blackdrag blackdrag [ 09/Nov/12 ]

I moved the issue to the groovy eclipse team jira for further inspection

Comment by Andrew Eisenberg [ 09/Nov/12 ]

Thanks for the sample project. Taking a look right now.

Comment by Andrew Eisenberg [ 09/Nov/12 ]

I see what the problem is. Groovy-Eclipse hand;es certain built-in transformations specially. We were making the assumption that @Immutable refers to the builtin groovy transform and this was causing problems. I have a fix on the Eclipse 4.2 branch. I'm pushing it out now and the fix should be available in a few hours.

The snapshot update site is here:
http://dist.springsource.org/snapshot/GRECLIPSE/e4.2/

Please upgrade when it is available and let me know if it works. I can backport to the e37 branch if you need.

Comment by Peti Koch [ 09/Nov/12 ]

Hi Andrew!

Thanks for the fast answer.

I'll check it in the office when I'm back on monday 19th, I'm at Devoxx next week...

Best regards,
Peti

Comment by Peti Koch [ 19/Nov/12 ]

Hi Andrew,

my provided example (the one in the description of the task) works fine now with the latest snapshot from http://dist.springsource.org/snapshot/GRECLIPSE/e4.2/.

But I found another small issue in the same area with code completion and the groovy eclipse compiler:


package example

import net.jcip.annotations.Immutable

@Immutable
class B {

  final String someFinalValue = "already assigned"
}

When I try to use class B in class C, greclipse offers me a non existing constructor. This compiles fine in eclipse, fails then at runtime.


package example

class C {

  public static void main(String[] args) {
    B b = new B("no no no") // def. wrong
    println b
  }
}

Strange... good luck!

Comment by Andrew Eisenberg [ 19/Nov/12 ]

Thanks for the response and hope you enjoyed Devoxx.

What's happening here is that the reconciler is still treating the annotation as the builtin groovy Immutable annotation. At the point in the analysis when we need to determine how to handle the annotation, we don't have enough information to distinguish between the various kinds of @Immutable annotations.

Comment by Andrew Eisenberg [ 19/Nov/12 ]

I've written things more correctly and added a few regression tests. It is now correctly looking for imports before trying to apply the Immutable annotation to the source.

Comment by Andrew Eisenberg [ 19/Nov/12 ]

Pushed the fix will be available in next snapshot build.

Comment by Andrew Eisenberg [ 04/Jan/13 ]

Have you had a chance to try this fix out? Please let me know so we can determine if we can close this issue.

Comment by Peti Koch [ 07/Jan/13 ]

Andrew, with which version I can check the fix?
It's tagged with fixed for 2.8.0, but I have "only" 2.7.2

Comment by Andrew Eisenberg [ 07/Jan/13 ]

Fix is in the snapshot build. Use this update site:

http://dist.springsource.org/snapshot/GRECLIPSE/e4.2/

Rhis fix did make it into 2.7.2. I didn't resolve the bug for 2.7.2 since I never heard back from anyone confirming the fix. That is why there is a 2.8.0 tag on it.

Are you still seeing the problem?

Comment by Peti Koch [ 15/Jan/13 ]

Seems to work in 2.7.2, thanks!

Comment by Andrew Eisenberg [ 15/Jan/13 ]

Thanks for getting back to me. Resolving.





[GRECLIPSE-1546] Problem with CompileStatic and type inference Created: 05/Nov/12  Updated: 23/May/13  Resolved: 23/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by GROOVY-6168 STC bug with generics Open
Number of attachments : 0

 Description   

I don't know if this is also a Groovy compiler bug. However consider the following Java class:

package test;

import groovy.lang.Closure;

public class TestStaticJ
{
	public <T> T doSomething(Closure<T> closure)
	{
		return closure.call();
	}
}

and the following Groovy class:

package test

import groovy.transform.CompileStatic;

class TestStaticG {

	@CompileStatic
	List<String> test() {
		TestStaticJ t = new TestStaticJ()
		t.doSomething {
			return new ArrayList<String>()
		}
	}
}

An error is given on t.doSomething():

Groovy:[Static type checking] - Cannot call test.TestStaticJ#doSomething(groovy.lang.Closure 
 <java.lang.Object>) with arguments [groovy.lang.Closure <java.util.ArrayList>]

Now, consider this variant:

package test

import groovy.transform.CompileStatic;

class TestStaticG {

	@CompileStatic
	List<String> test() {
		TestStaticJ t = new TestStaticJ()
		return t.doSomething {
		}
	}
}

Now the error is:

Groovy:[Static type checking] - Cannot return value of type java.lang.Object on method returning type 
 java.util.List <String> -> java.util.List <E extends java.lang.Object>

However in both cases the generic type parameter <T> should be simply inferred as List<String>, which is perfectly legal as the following Java equivalent class demonstrates:

package test;

import groovy.lang.Closure;

import java.util.ArrayList;
import java.util.List;

public class TestStaticJ2
{
	public void test1()
	{
		TestStaticJ t = new TestStaticJ();
		t.doSomething(new Closure<List<String>>(this)
			{
				@Override
				public List<String> call()
				{
					return new ArrayList<String>();
				}
			});
	}

	public List<String> test2()
	{
		TestStaticJ t = new TestStaticJ();
		return t.doSomething(new Closure<List<String>>(this)
			{
				@Override
				public List<String> call()
				{
					return null;
				}
			});
	}
}


 Comments   
Comment by Andrew Eisenberg [ 05/Nov/12 ]

Briefly looking, this does seem like a Greclipse problem. A compile on the command line showed no problems. I am guessing that the generics involved are not being properly interpreted inside of eclipse.

Comment by Andy Clement [ 28/Nov/12 ]

Problem #1 is now fixed in groovy-eclipse.
Problem #2 seems to happen on the command line with groovy 2.0.4 so isn't just a groovy-eclipse issue.

Comment by Paul King [ 28/Nov/12 ]

Any chance you can check Problem #2 on the command line with Groovy 2.0.5? There was a bug related to this fixed in that version - but not sure it was exactly the same issue.

Comment by Mauro Molinari [ 29/Nov/12 ]

I tried this:

g:\Supporto\Groovy\test>..\groovy-2.0.5\bin\groovyc.bat -v
Groovy compiler version 2.0.5
Copyright 2003-2011 The Codehaus. http://groovy.codehaus.org/

and:

g:\Supporto\Groovy\test>..\groovy-2.0.5\bin\groovyc.bat .\test\TestStaticJ.java
.\test\TestStaticG.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
.\test\TestStaticG.groovy: 10: [Static type checking] - Cannot return value of t
ype java.lang.Object on method returning type java.util.List <String> -> java.ut
il.List <E extends java.lang.Object -> java.lang.Object>
 @ line 10, column 10.
                return t.doSomething {
            ^

1 error
Comment by Andrew Eisenberg [ 22/Apr/13 ]

Still a problem.

Comment by Andrew Eisenberg [ 23/May/13 ]

Not a greclipse problem. Still failing on Groovy 2.1.3 happening on the command line. Will raise a groovy bug and close this one.

Comment by Andrew Eisenberg [ 23/May/13 ]

Opened GROOVY-6168.





[GRECLIPSE-1544] Errorneous "No such property" compilation error Created: 01/Nov/12  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Linas Ablonskis Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Mint v12 64bits, OpenJDK, Java 1.7.0_09


Attachments: File BugClass.groovy     File SourceClass.groovy    
Number of attachments : 2

 Description   

Groovy (compiler v2.0.4) fails to find a field/property of the class if the instance of a class is accessed in a certain way. See the attached files for the scenario.

The lines
someVar = SourceClass.getInstance().SOME_PROP;
someVar = SourceClass.getInstance().SOME_FINAL_PROP;

in the file BugClass.groovy fail to compile with messages
Groovy:[Static type checking] - No such property: SOME_PROP for class: SourceClass
Groovy:[Static type checking] - No such property: SOME_FINAL_PROP for class: SourceClass

The bug goes away if @TypeChecked is removed from any of the classes.

The bug does not manifest itself on full rebuild of the sources (Clean & Build). It manifests if changes are made (for example add and remove a space symbol) to any of the files, then files are saved and thus a build is triggered.

Eclipse error log shows nothing.



 Comments   
Comment by Andrew Eisenberg [ 01/Nov/12 ]

Thanks for the bug report. There are a number of TypeChecked related bugs out there. We will be addressing all of them for the 2.7.2 release.

Comment by Andrew Eisenberg [ 27/Nov/12 ]

Still a problem on the generics branch.

Comment by Andrew Eisenberg [ 11/Mar/13 ]

Should check this issue again. According to comment in GRECLIPSE-1551, this issue is now fixed.

Comment by Andrew Eisenberg [ 19/Mar/13 ]

Confirmed fixed. However, the fix uncovered a type inferencing error. Static class references that are being statically type checked have a type of java.lang.Class with a type parameter to specify the actual class. Whereas, static class references that are not being statically type checked have a type of the specified class.

I need to extend the inferencing engine to handle both kinds of class references.

I have a fix with regression tests. Pushing it now.





[GRECLIPSE-1543] Add Eclipse-Tycho support for developing eclipse plugins in groovy Created: 31/Oct/12  Updated: 31/Jan/13  Resolved: 31/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Pull request on github https://github.com/groovy/groovy-eclipse/pull/2

Seeing if this works as advertised.



 Comments   
Comment by Andrew Eisenberg [ 31/Oct/12 ]

Using project from GRECLIPSE-1418 as a sample project.

Comment by Andrew Eisenberg [ 31/Jan/13 ]

Done.





[GRECLIPSE-1542] Links to latest development version of Greclipse for e4.2 and e3.7 wrong on website Created: 31/Oct/12  Updated: 31/Oct/12  Resolved: 31/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Minor
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I'm pretty sure links for the latest development version of Greclipse is wrong on Groovy website at http://groovy.codehaus.org/Eclipse+Plugin

Current links:
4.2 (Juno) http://dist.springsource.org/milestone/GRECLIPSE/e4.2/
3.7 (Indigo) http://dist.springsource.org/milestone/GRECLIPSE/e3.7/
3.6 (Helios) http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/
3.5 (Galileo) http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.5/

Correct links (I think)
4.2 (Juno) http://dist.springsource.org/snapshot/GRECLIPSE/e4.2/
3.7 (Indigo) http://dist.springsource.org/snapshot/GRECLIPSE/e3.7/
3.6 (Helios) http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/
3.5 (Galileo) http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.5/



 Comments   
Comment by Andrew Eisenberg [ 31/Oct/12 ]

Foxed! Thanks for catching.





[GRECLIPSE-1541] Unable to resolve Java Enum from a Groovy class Created: 28/Oct/12  Updated: 28/Oct/12  Resolved: 28/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Critical
Reporter: Mauro Molinari Assignee: Unassigned
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I have a serious issue which is forcing me to throw away a Groovy class and rewrite it in Java... Unfortunately I couldn't reproduce it in a small test case to post here, because even if I copied the offending classes (a Groovy class and a Java enum) exactly as they are (copy and paste!) on a new project, I couldn't reproduce the problem there.

Actually, I have a Groovy class that is implementing javax.servlet.Filter. In the implementation of doFilter(ServletRequest, ServletResponse, FilterChain) I'm invoking the valueOf() method on a Java enum, something like this:

MyJavaEnum value = MyJavaEnum.valueOf(myString)

MyJavaEnum is located in the same package of the Groovy class, so no import is needed. The problem is that in my production project Groovy gives the following error on the declaration of value: "Groovy:unable to resolve class MyJavaEnum".
If I want Greclipse to compile my Groovy class, I must change my code to:

def value = MyJavaEnum.valueOf(myString)

However, another problem occurs then: at runtime I get the following error:

groovy.lang.MissingPropertyException: No such property: MyJavaEnum for class: fully.qualified.name.MyGroovyClass

I even tried to change like this:

def value = fully.qualified.name.MyJavaEnum.valueOf(myString)

But then the runtime error is:

groovy.lang.MissingPropertyException: No such property: fully for class: fully.qualified.name.MyGroovyClass

So, I'm stuck and I don't know how to solve and/or to better diagnose this problem. Any suggestion would be appreciated.



 Comments   
Comment by Mauro Molinari [ 28/Oct/12 ]

Please ignore this issue. It was caused by JDT not building my project correctly because of JDT bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=354226





[GRECLIPSE-1540] Inspection of a getter access using Groovy myObject.property syntax does not work Created: 28/Oct/12  Updated: 23/Apr/13  Resolved: 22/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Put a breakpoint on a Groovy class and debug your application. Suppose you have an object whose class exposes a getter method (example: getFoo()) with no corresponding foo field. Suppose you're using myObj.foo in your Groovy code and try to inspect myObj.foo: Eclipse says that "foo cannot be resolved or is not a field".

I would expect Greclipse to "translate" the highlighted expression to the corresponding getFoo() method call, so that inspection works.



 Comments   
Comment by Andrew Eisenberg [ 31/Oct/12 ]

Are you using GGTS or grails-ide? Enhanced debug support is only available in GGTS because it relies on using AspectJ. With grails-ide installed, I have not rouble inspecting this:

class Other {
	String getFoo() {
		"ji"
	}
}

println new Other().foo

set breakpoint on the println and launch in debug mode. When stopped at breadkpoint, select new Other().foo and Ctrl+Shift+I. Value is as expected.

Are you seeing different behavior?

Comment by Andrew Eisenberg [ 22/Apr/13 ]

Please re-open or comment if you still have the problem.

Comment by Mauro Molinari [ 23/Apr/13 ]

I remember we discussed about this topic but I can't find my thoughts (maybe they're on another issue).

I still think that the enhanced Greclipse debug capabilities should be taken off GGTS and put in another plugin Greclipse can optionally depend on. Said that they both are open-source software, I can hardly understand why I should install the whole GGTS bundle just to be able to highlight a Groovy expression in the debugger, without needing anything about Grails or even Spring.

If you prefer, I may open a dedicated enhancement request for this.

Comment by Andrew Eisenberg [ 23/Apr/13 ]

That's a possibility now that STS and GGTS are open source. The downside is that it makes the build and distribution process of groovy-eclipse significantly more complicated. But, I can see an advantage of this.

Comment by Andrew Eisenberg [ 23/Apr/13 ]

Opened GRECLIPSE-1619 for migrating the feature.





[GRECLIPSE-1539] While debugging and in debug perspective, the Groovy editor contextual menu does not show debug menu items Created: 28/Oct/12  Updated: 01/Nov/12  Resolved: 31/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Testing, Running, Debugging
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Minor
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Put a breakpoint on a Groovy class, then debug your application.
When your breakpoint is hit, highlight some code in your Groovy editor, then right click in the editor and search for debug menu items like "Watch", "Inspect", "Display", "Run to line", etc.: they are missing.

You must search for them under "Run" main menu. Appropriate context menu items like in the Java editor would be very appreciated.



 Comments   
Comment by Andrew Eisenberg [ 31/Oct/12 ]

Menu items are available in GGTS only since that is where the enhanced debug support exists.

Comment by Mauro Molinari [ 01/Nov/12 ]

Hi Andrew,
sorry but I don't understand. I'm not using any SpringSource Eclipse distribution, but just an Eclipse Platform Runtime on top of which I have installed Greclipse (and also the Spring Tool Suite, for other reasons). Will I see these context menus with Greclipse 2.7.2?

Comment by Andrew Eisenberg [ 01/Nov/12 ]

The extra functionality comes with grails-ide. You must have that installed in order to get the enhanced debugging support.

Comment by Mauro Molinari [ 01/Nov/12 ]

Hmmm... I can't quite understand this choice. I am forced to install the full Grails IDE plugin (I even don't know how many things it will install I actually don't need...) just to have Groovy debugging support comparable to that of JDT for projects that do not use Grails at all...

If GGTS were a commercial product I may understand: in that case, enhanced debugging support may be seen as an added feature of the product, but we're talking about all open source software...

Comment by Andrew Eisenberg [ 01/Nov/12 ]

You don't need all of GGTS, just grails-ide. If you already have STS installed, then you have 90% of what you get anyway.

The debug support is in GGTS because it requires AspectJ and AJDT. We did not want to make Groovy-Eclipse have a dependency on AJDT, so we kept the debugging support in Grails-ide only.

Comment by Mauro Molinari [ 01/Nov/12 ]

An alternative could be to provide another package "Groovy-Eclipse Enhanced Debug Support plugin" with a dependency on AJDT: one will install it only if he needs the enhanced debug capabilities. Then, the Grails-IDE plugin will have a dependency on this new "Groovy-Eclipse Enhanced Debug Support plugin".

I still feel it's inconvenient to install the whole Grails-IDE plugin just to have full debug support for Groovy applications, when I don't need support for Grails. I'm always against polluting my Eclipse installation with unneeded features that just slow down things. Please consider this point of view.

Comment by Andrew Eisenberg [ 01/Nov/12 ]

Perhaps a solution would be to provide a composite update site that lists all of the separate groovy-eclipse and grails-ide features together. I would also need to refactor the debugging support into its own, separately installable feature.





[GRECLIPSE-1538] Rename refactoring not available on a enum method Created: 28/Oct/12  Updated: 05/May/14  Resolved: 25/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Denis Murashev
Resolution: Fixed  
Labels: help-requested, wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
depends upon GROOVY-5777 inner enum method not recognized Closed
Number of attachments : 0

 Description   

Consider the following Groovy enum:

package b;

enum R {

	A() {
		@Override
		String getFoo() {
		}
	},
	B() {
		@Override
		String getFoo() {
			"bar"
		}
	}

	String getFoo() {
	}
}

Now highlight getFoo on either A or B definition and try to rename it with Alt+Shift+R: Groovy says "Cannot refactor on current selection. No refactoring candidates found". In a Java enum you can do that (it obviously changes getFoo() in the base enum definition, too).

Now highlight getFoo on the base enum definition (i.e.: the last getFoo() declaration): here you can issue a rename, but the rafactor doesn't update either A.getFoo() or B.getFoo(). I know Groovy is dynamic, however:

  • both A.getFoo() and B.getFoo() are marked with @Override, so there's no doubt they are overridings of R.getFoo()
  • even if they were not marked with @Override, I would expect Greclipse to suggest their change too by using the refactoring wizard preview


 Comments   
Comment by Andrew Eisenberg [ 31/Oct/12 ]

The root problem is GROOVY-5777. When groovy can produce an AST that groovy-eclipse can recognize, this should be working.

Comment by Denis Murashev [ 25/Apr/14 ]

It was already fixed





[GRECLIPSE-1537] Refactoring of Java getter ignores Groovy code Created: 28/Oct/12  Updated: 31/Oct/12  Resolved: 31/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following Java Enum:

package b;

public enum RJ
{
	A,
	B
	{
		@Override
		public String getFoo()
		{
			return "g";
		}
	};

	public String getFoo()
	{
		return "f";
	}
}

And the following Groovy class:

package b

class TestRJ {

	static main(args) {
		String f = RJ.A.foo
	}
}

Now, issue a rename refactoring for RJ.getFoo() and change its name to RJ.getBar(). The TestRJ class is not updated and Greclipse simply underlines foo in RJ.A.foo (in a production project I even had to make a change to the file in order to force Groovy to revalidate the file and underline the corresponding foo access).

I know Groovy is dynamic, so I don't expect Greclipse to simply change to RJ.A.bar without any advice. But I would expect it to force a preview in the refactoring wizard where all the changes of this type are listed and where I can uncheck if I don't want Greclipse to change RJ.A.foo to RJ.A.bar.



 Comments   
Comment by Andrew Eisenberg [ 31/Oct/12 ]

Fixed. Was missing a case. Now properly refactoring when the target getter/setter is defined in a java class.





[GRECLIPSE-1535] Code assist not working for parameters when implementing a method for an enum value Created: 27/Oct/12  Updated: 31/Oct/12  Resolved: 31/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by GROOVY-5777 inner enum method not recognized Closed
Number of attachments : 0

 Description   

Consider the following:

package a;

import javax.swing.JFrame;


/**
 * aaa
 * 
 * @author mauro
 */
enum F {

	/** aaa */
	A() {
		@Override
		String myMethod(JFrame frame) {
			fr|
		}
	},
	B() {
		@Override
		String myMethod(JFrame frame) {
			"bar"
		}
	}

	/**
	 * aaa
	 * 
	 * @return
	 */
	String myMethod(JFrame frame) {
	}
}

Place your cursor at "|" and hit Ctrl+Space: no suggestion is given for "frame" parameter name.



 Comments   
Comment by Andrew Eisenberg [ 31/Oct/12 ]

All of these enum bugs you have raised recently are likely related. Enums are compiled by groovy through a series of transformations. These transformations tend to muck with source locations in such a way that our editing support breaks inside of enums.

I'll take a look to see if there's some way I can make the source locations saner and get these things working again.

Comment by Andrew Eisenberg [ 31/Oct/12 ]

Actually, this appears to be a groovy bug. Using this code:

import javax.swing.JFrame;

enum F {
    A() {
        @Override
        String myMethod() {
            return "inner";
        }
    };
    String myMethod() {
        return "outer";
    }
}

print F.A.myMethod()

compile and run under 2.0.4 and I get:

outer

Will raise a groovy jira for this.

Comment by Andrew Eisenberg [ 31/Oct/12 ]

See GROOVY-5777. This issue will be closed.

Comment by Andrew Eisenberg [ 31/Oct/12 ]

We will pick up the fix from the groovy compiler.





[GRECLIPSE-1534] Enum outline shows unknown members Created: 27/Oct/12  Updated: 31/Oct/12  Resolved: 31/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Minor
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following:

package a;

import javax.swing.JFrame;


/**
 * aaa
 * 
 * @author mauro
 */
enum F {

	/** aaa */
	A() {
		@Override
		String myMethod(int i) {
			"foo"
		}
	},
	B() {
		@Override
		String myMethod(int i) {
			"bar"
		}
	}

	/**
	 * aaa
	 * 
	 * @return
	 */
	String myMethod(int i) {
	}
}

Look at the Outline view: it shows also a static field MAX_VALUE, a static field MIN_VALUE and two methods previous() and next(). These are not part of my enum declaration.

Then, remove the () parenthesis after A and B enumeration value definitions: the Outline view now also shows two nested enumerations (!?) named 1 and 2...



 Comments   
Comment by Andrew Eisenberg [ 31/Oct/12 ]

All of the members in the outline view do exist in the byte code. They are just erroneously being added to the outline view when they should be ignored.

Comment by Andrew Eisenberg [ 31/Oct/12 ]

OK. Fixed. Not as clean of a solution as I would have liked since there is no test to see if a method/field has been generated. I am just going through a hard-coded list of names to see which fields and methods to remove for enums. Seems to work fine now. Fix will be available in next snapshot version.

Comment by Andrew Eisenberg [ 31/Oct/12 ]

Fixed.





[GRECLIPSE-1532] After update to Juno and 2.7.1, formatter seems to have stopped responding Created: 25/Oct/12  Updated: 01/Nov/12  Resolved: 01/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Jon Williams Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Juno, Win 7


Attachments: Microsoft Word greclipseFormatterIssue.doc    
Number of attachments : 1

 Description   

Clicking Source/Format or pressing Ctrl-Shift-F appears to have no effect after updating to Greclipse 2.7.1 (Eclipse Juno)



 Comments   
Comment by Andrew Eisenberg [ 25/Oct/12 ]

The sample code is formatting as expected for me. Please check your error log. Window -> Show view -> Other -> error log. Paste any relevant errors.

If you still see problems, please package your sample code in a small project so that I can try to reproduce your exact scenario.

Comment by Jon Williams [ 25/Oct/12 ]

Replied to the automail with this info, posting here also.

I couldn't make more "Keybinding conflict" messages appear. 8:54 appears to be about 20 minutes after I started Eclipse today.

eclipse.buildId=M20120914-1800
java.version=1.7.0
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product -Xmx<1024M>
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product -Xmx<1024M>

Warning
Thu Oct 25 08:54:56 CDT 2012
A conflict occurred for CTRL+SHIFT+F:
Binding(CTRL+SHIFT+F,
                ParameterizedCommand(Command(org.eclipse.jdt.ui.edit.text.java.format,Format,
                                Format the selected text,
                                Category(org.eclipse.jdt.ui.category.source,Source,Java Source Actions,true),
                                org.eclipse.ui.internal.MakeHandlersGo@5ee24496,
                                ,,true),null),
                org.eclipse.ui.defaultAcceleratorConfiguration,
                org.eclipse.jdt.ui.javaEditorScope,,,system)
Binding(CTRL+SHIFT+F,
                ParameterizedCommand(Command(org.eclipse.wst.sse.ui.format.document,Format,
                                Format selection,
                                Category(org.eclipse.ui.category.edit,Edit,null,true),
                                org.eclipse.ui.internal.MakeHandlersGo@6b6dc913,
                                ,,true),null),
                org.eclipse.ui.defaultAcceleratorConfiguration,
                org.eclipse.wst.sse.ui.structuredTextEditorScope,,,system)
Comment by Jon Williams [ 25/Oct/12 ]

See my email reply to your previous comment's email notification for a screenshot. I keep getting, "Whoa. Google chrome crashed." error messages when I click the "Attach Screenshot" tab above, even though I am using IE8.

Comment by Andrew Eisenberg [ 25/Oct/12 ]

I didn't get any email from you. You can send a message here: andrew@eisenberg.as, but the screenshot wouldn't be very useful anyway.

Here's how to address the problem:

  1. go to Preferences -> General -> Keys
  2. in the filter box, type format
  3. you should see a bunch of {{C}}s next to the keybindings that are conflicting. You also may see a U next to the binding for formatting in structured editors.
    1. If you see a U, then select that command and click Restore Command. Problem should go away
    2. If you just see a bunch of {{C}}s, then select the command labeled Format selection and change the when box to Editing in structured text editors
Comment by Jon Williams [ 26/Oct/12 ]

I replied to andrew@eisenberg.as yesterday. Repeating most of it here.

I didn't see any C's in the filtered Keys preferences list, and I didn't see a command labeled Format Selection. I see 5 Format Commands, 4 of them are bound to Ctrl+Shift+F when editing Ant Buildfiles, java source, javascript source, and in structured text docs. 3 of them are in the Source category, and the Structured Text one is in the Edit category. The fifth Format command I can see is in the Groovy Source Commands category, but it has no binding and no when. If I add the Crtl+Shift+F binding when Editing in Structured Text Editors to the Groovy Source Commands category format command, then I get CU in the user column of that row and C in the user column of the other row where when Editing in Structured Text Editors is in the When column (the row in the Edit category). If I change the When selection of the row in the edit category, then both rows get a U in the user column (no C). If I click OK on this configuration, Source/format and Ctrl+Shift+F still have no apparent effect.

This same issue has also occurred for me after a full fresh installation of Greclipse Juno.

Comment by Andrew Eisenberg [ 26/Oct/12 ]

You should see some {{C}}s somewhere. The error message that you posted earlier means that there is a conflict. Specifically, the error message means that the structured text editor formatting command (used inside of HTML/XML, etc editors) is conflicting with the command for formatting in Java editors (also used by the groovy editor).

Are you still seeing this message in your log? If not, then something else is going on.

Also, what language/locale are you using (eg- en_US, en_CA, etc). You can find this in Help -> About Eclipse -> Installation details -> Configuration

Look for the property osgi.nl. This value has an effect on keybindings.

Comment by Andrew Eisenberg [ 31/Oct/12 ]

Any update here?

Comment by Jon Williams [ 01/Nov/12 ]

I happened to be in a different workspace yesterday, and I couldn't reproduce the problem, so the issue appears to be isolated to one of my workspaces. I still haven't resolved the problem for that one workspace, but I am going to mark this issue resolved here.

Comment by Jon Williams [ 01/Nov/12 ]

problem appears to be isolated to a single local workspace, and not a general formatting issue.

Comment by Andrew Eisenberg [ 01/Nov/12 ]

Thanks for getting back to me on this.





[GRECLIPSE-1529] Ability to set project compiler level from project context menu Created: 24/Oct/12  Updated: 31/Jan/13  Resolved: 31/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Project Settings
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It would be nice to be able to right-click on a project (or projects) and set the compiler level(s) all at once using a context menu command.



 Comments   
Comment by Andrew Eisenberg [ 24/Oct/12 ]

Best would be able to be able to change the setting on all projects at once.

Comment by Andrew Eisenberg [ 31/Jan/13 ]

Done.





[GRECLIPSE-1528] Add create setter/getter proposal Created: 24/Oct/12  Updated: 05/May/14  Resolved: 30/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Mauro Molinari Assignee: Denis Murashev
Resolution: Fixed  
Labels: help-requested, wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following:

package a

import javax.swing.JFrame

class TestF {

  private JFrame frame
 
  |	
}

Place the cursor at "|" and hit Ctrl+Space: no proposal is suggested to create a getter and/or a setter for "frame" field.

This works in the Java editor and it's extremely useful.



 Comments   
Comment by Alex Boyko [ 08/Apr/14 ]

Also missing action "Generate Getters and Setters..." under Source menu group when the field statement is selected...

Comment by Denis Murashev [ 16/Apr/14 ]

Groovy has implicit get and set methods for each field.
Is this feature really needed?

Comment by Mauro Molinari [ 16/Apr/14 ]

You may need/wish to define non-trivial getter and/or setter methods, which will then be used by Groovy in place of the implicit ones. Two typical cases are lazy getters or setters that perform some sort of input validation (assertions or such).
So, yes, it would be useful to have these features.

Comment by Denis Murashev [ 30/Apr/14 ]

Generated code will use Java style (like for existing Override/Implement Methods feature).
To make generated code more "Groovish" new Groovy code generator for all cases is needed (I mean for Getters and Setters, Override/Implement and so forth). I think it should be separate task.

Comment by Mauro Molinari [ 30/Apr/14 ]

Hi Denis,
thanks to you and all the new guys that are working on Greclipse now!!
I just have a suggestion: the release management is quite obscure now. In JIRA there's a 2.9.0 release which was never released and with a lot of unresolved targeted issues on it. On the other hand, recently I saw some fixes with no target milestone set at all. So it's quite hard to understand which version is supposed to contain the fix and what is the contents of the plugin at a certain point in time.

Comment by Kris De Volder [ 30/Apr/14 ]

@Mauro, yes some 'housecleaning' is in order for the issues looking for 'issues with issues' like you describe. (Fixed issues should be tagged with fix release number, issues with no 'target release' should be triaged).

It also has been a while since an official release of Greclipse came out, 2.9.0 release is supposed to be the next 'official' release but no date is really set yet for that.
Except for the long delay between 2.8.0 and 2.9.0 this state of having issues targeted for a release that didn't come out yet is not unusual, it is always the case when an issue gets fixed it is getting tagged with the next official release number.

As more people joined the team recently, releases will hopefully start going smoother again. But it will take some time to get that 'release train' running again.

@Denis: I agree issues with Override / Implement generated codes are separate issues. You could raise them as needed.
This issue is only about getter / setters.





[GRECLIPSE-1527] Code assist showing no proposals when defining a private field Created: 24/Oct/12  Updated: 10/Jun/14  Resolved: 10/Jun/14

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Parser
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Denis Murashev
Resolution: Fixed  
Labels: help-requested, triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider this:

package a

class TestF {

	private JFr|

	public void test() {
		
	}
}

Place the cursor at "|" and invoke code assist, searching in vain for "JFrame"...



 Comments   
Comment by Andrew Eisenberg [ 24/Oct/12 ]

The problem here is with parser recovery. When you type private JFr, the parser falls apart since it cannot recover from the syntax error and it cannot produce proposals if there is not AST.

Comment by Denis Murashev [ 04/Jun/14 ]

It looks like the problem is caused by incorrect logic in method org.codehaus.groovy.eclipse.codeassist.processors.TypeCompletionProcessor.shouldShowTypes(ContentAssistContext, String)
So proposals generating code assumes that "JFr" is not a part of type name, but part of variable name.





[GRECLIPSE-1526] "Assign statement to local variable" not honouring selection Created: 24/Oct/12  Updated: 06/Mar/14  Resolved: 06/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.9.0.Release

Type: Improvement Priority: Major
Reporter: Mauro Molinari Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following:

package a;

import javax.swing.JFrame;


/**
 * aaa
 * 
 * @author mauro
 */
enum F {

	/** aaa */
	A() {
		@Override
		String myMethod(int i) {
			"foo"
		}
	},
	B() {
		@Override
		String myMethod(int i) {
			"bar"
		}
	}

	/**
	 * aaa
	 * 
	 * @return
	 */
	String myMethod(int i) {
	}
}

and:

class TestF {

	public void test() {
		F.valueOf("A").myMethod(0)
	}
}

Now, in TestF highlight "F.valueOf("A")", hit "Ctrl+1" and "Assign statement to new local variable".

Expected result:

def valueOf = F.valueOf("A")
valueOf.myMethod(0)

Actual result:

def myMethod = F.valueOf("A").myMethod(0)


 Comments   
Comment by Alex Boyko [ 06/Mar/14 ]

Use "Extract to Local Variable" quick fix to perform this operation. This quick fix should be available in 2.9.0 build after March 5, 2014 or GGTS 3.5.0 RC1





[GRECLIPSE-1524] "Assign to local variable" quick fix not proposed for arithmetic operation Created: 23/Oct/12  Updated: 06/Mar/14  Resolved: 06/Mar/14

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Alex Boyko
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following code:

package a

class TestF {

	public PrintStream test() {
		def a = 1
		def b = 2

		a + b
	}
}

Highlight "a + b" and hit Ctrl+1: "Assigned statement to local variable" is not proposed.

The example is dumb. A more smart example code be:

package a

class TestF {

	public PrintStream test() {
		def a = 1
		def b = 2
		def c = 3
		def d = a + b + c
	}
}

Highlight "a + b" and invoke quick fix: the "assign statement to local variable" is not proposed.



 Comments   
Comment by Andrew Eisenberg [ 22/Apr/13 ]

There is a bit of confusion here, but you have uncovered a real issue. I think you are looking for the extract local variable refactoring, not the assign statement to local variable. When I apply the refactoring, then this works as expected.

The assign statement to local variable quickfix is a bit more simplistic. All it does is take the statement and add a "def temp = " in front of it. This will not be proposed for def statements (as in your second example). Nor will it be applied to return statements. In your first example. a + b is implicitly turned into a return statement since it is the last line of a method body with no other return statement.

The expectation is that the quickfix should apply (and I agree that this is the best behavior), but it currently does not because it is an implicit return statement. This is the bug that you have uncovered.

Comment by Mauro Molinari [ 23/Apr/13 ]

Well, actually in the first case I really mean the "assign statement to new local variable", as you say. It's not proposed.

In the second case I actually mean the "extract local variable" refactoring. I just tried with 2.8.0.xx-20130304-1200-e42 and after highlighting a+b the only quickfixes proposed are "Remove unnecessary semicolons" (well I don't have one! :-D) and "Swap infix operands". So I confirm I don't see the "extract local variable" quickfix.

So, these are two separate issues, but really similar in practice.

Comment by Andrew Eisenberg [ 23/Apr/13 ]

Perhaps it's a bit unclear. There is a difference between a quickfix and a refactoring. Quickfixes are meant to just execute without any user interaction required. They can be invoked from CTRL+1. A refactoring typically pops up a dialog and requires some user interaction and they are accessed from the refactoring context menu. Assign statement to local is a quick fix because all it does is add a variable declaration to the beginning of the statement. Extract local variable is a refactoring because it will potentially make changes in several parts of the code (ie- wherever the extraction pattern is found).

Perhaps I could start adding refactorings to the quickfix menu, but that is not usually how the UI is done in Eclipse.

Comment by Mauro Molinari [ 23/Apr/13 ]

Well, in the JDT Java Editor, the "Extract to local variable" is indeed in the quickfix menù (Ctrl+1).

Comment by Andrew Eisenberg [ 23/Apr/13 ]

Good point. In recent versions of Eclipse, more and more refactorings are being exposed as quickfixes. Groovy-Eclipse should do the same. I will raise a new bug for this.

Comment by Andrew Eisenberg [ 23/Apr/13 ]

See GRECLIPSE-1620.





[GRECLIPSE-1523] Assign to local variable quick fix not working when expression is returned Created: 23/Oct/12  Updated: 23/Apr/13  Resolved: 22/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following:

package a

class TestF {

	public PrintStream test() {
		System.out
		return System.out
	}
}

1. Highlight "System.out" and hit Ctrl+1: "Assign statement to local variable" is proposed
1. Highlight "return System.out" and hit Ctrl+1: "Assign statement to local variable" is not proposed



 Comments   
Comment by Andrew Eisenberg [ 22/Apr/13 ]

Duplicate of GRECLIPSE-1524.

Comment by Mauro Molinari [ 23/Apr/13 ]

I think you meant GRECLIPSE-1524. But maybe we should better keep this for the problem of the "assign to local variable" not shown when you have the return statement (either implicit of explicit) and keep the other one for the missing "extract local variable" refactoring.

Comment by Andrew Eisenberg [ 23/Apr/13 ]

Thanks. I did mix up the issue number. See my comment there as to why this feature is a duplicate.





[GRECLIPSE-1522] Code assist not working in enum in a special condition Created: 23/Oct/12  Updated: 08/May/14  Resolved: 22/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: help-requested, wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following code:

package a;

import javax.swing.JFrame;

/**
 * aaa
 * 
 * @author mauro
 */
enum F {

	/** aaa */
	A() {
		@Override
		String myMethod(int i) {
			JFrame f = new JFr|
			"foo"
		}
	},
	B() {
		@Override
		String myMethod(int i) {
			"bar"
		}
	}

	/**
	 * aaa
	 * 
	 * @return
	 */
	String myMethod(int i) {
	}
}

Invoke code assist at "|": JFrame constructor is not proposed.

Now remove the "()" beside the definition of enum values A and B: code assist will then work.



 Comments   
Comment by Alex Boyko [ 03/Mar/14 ]

Appears to be fixed in 2.9.0 rc1

Comment by Mauro Molinari [ 04/Mar/14 ]

With GRECLIPSE 2.9.0.xx-20130828-1400-e43-RELEASE, the one available from the stable update site, I don't get any proposal yet.
Which exact version do you mean?

Comment by Alex Boyko [ 04/Mar/14 ]

My bad... I've tried the latest dev code. It translates to:

Groovy/Grails Tool Suite

Version: 3.5.0.RC1
Build Id: 201402270903

Next coming Groovy Eclipse release should have this issue fixed

Comment by Alex Boyko [ 22/Apr/14 ]

Fix is https://github.com/groovy/groovy-eclipse/pull/31
Fix contributed by Vasiliy Kizhaev





[GRECLIPSE-1521] StackOverflowError when using @CompileStatic with class holding inner enum definition Created: 20/Oct/12  Updated: 19/Dec/12  Resolved: 14/Dec/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Joris Kuipers Assignee: Andy Clement
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive compilestaticbug.zip    
Testcase included: yes
Number of attachments : 1

 Description   

See the attached project to reproduce: I have a class that contains an inner enum definition. When I annotate that class with @CompileStatic the compiler goes into an infinite recursion, leading to a StackOverflowError.



 Comments   
Comment by Andrew Eisenberg [ 20/Oct/12 ]

Potentially related to GRECLIPSE-1514.

Comment by Andy Clement [ 14/Dec/12 ]

This particular problem appears to be fixed now (in dev builds). Probably due to the largescale generics handling rewrite in groovy-eclipse. The problems in 1514 still exist but that is a groovy bug.

Comment by Andy Clement [ 18/Dec/12 ]

the generics rewrite gets the test to pass in some circumstances but this exception has been seen when it is run as part of the full test suite, and in some runtime workbench setups.

java.lang.NullPointerException
	at org.eclipse.jdt.internal.core.builder.ClasspathDirectory.directoryList(ClasspathDirectory.java:46)
	at org.eclipse.jdt.internal.core.builder.ClasspathDirectory.doesFileExist(ClasspathDirectory.java:75)
	at org.eclipse.jdt.internal.core.builder.ClasspathDirectory.findClass(ClasspathDirectory.java:96)
	at org.eclipse.jdt.internal.core.builder.NameEnvironment.findClass(NameEnvironment.java:304)
	at org.eclipse.jdt.internal.core.builder.NameEnvironment.findType(NameEnvironment.java:322)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:122)
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:54)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:136)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superInterfaces(BinaryTypeBinding.java:1388)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:220)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:158)
	at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1091)
	at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1083)
	at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:1077)
	at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:1017)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.isAssignableTo(StaticTypeCheckingSupport.java:327)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.allParametersAndArgumentsMatch(StaticTypeCheckingSupport.java:198)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.chooseBestMethod(StaticTypeCheckingSupport.java:990)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.findMethod(StaticTypeCheckingVisitor.java:2535)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.findMethodOrFail(StaticTypeCheckingVisitor.java:2389)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.findMethodOrFail(StaticCompilationVisitor.java:265)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorCallExpression(StaticTypeCheckingVisitor.java:1390)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitConstructorCallExpression(StaticCompilationVisitor.java:227)
	at org.codehaus.groovy.ast.expr.ConstructorCallExpression.visit(ConstructorCallExpression.java:43)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1312)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructor(ClassCodeVisitorSupport.java:120)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1172)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:222)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:108)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:226)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:108)
	at org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:58)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1555)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:523)
	at org.eclipse.jdt.core.tests.compiler.regression.AbstractRegressionTest.runTest(AbstractRegressionTest.java:2114)
	at org.eclipse.jdt.core.tests.compiler.regression.AbstractRegressionTest.runConformTest(AbstractRegressionTest.java:1130)
	at org.eclipse.jdt.groovy.core.tests.basic.GroovySimpleTest.testGreclipse1521(GroovySimpleTest.java:328)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at junit.framework.TestSuite.runTest(TestSuite.java:243)
	at junit.framework.TestSuite.run(TestSuite.java:238)
	at org.eclipse.jdt.core.tests.util.CompilerTestSetup.run(CompilerTestSetup.java:55)
	at junit.framework.TestSuite.runTest(TestSuite.java:243)
	at junit.framework.TestSuite.run(TestSuite.java:238)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
	at org.eclipse.pde.internal.junit.runtime.PlatformUITestHarness$1.run(PlatformUITestHarness.java:47)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.runApp(NonUIThreadTestApplication.java:54)
	at org.eclipse.pde.internal.junit.runtime.UITestApplication.runApp(UITestApplication.java:41)
	at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.start(NonUIThreadTestApplication.java:48)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
Comment by Andy Clement [ 19/Dec/12 ]

The exception occurs because an old class node is being reused.

This occurs because the Enum classnode is 'cached' in ClassHelper. On encountering the first code that uses an enum, the various parts of the Enum type are partially resolved - those become JDTClassNode references rather than ClassNodes. Because Enum_Type is a final static in ClassHelper, these JDTClassNodes become anchored from it and are not cleared at the end of compilation. When a subsequent compile runs it can start resolving other bits of this partially resolved enum type (for example if the subsequent references were marked @CompileStatic). An attempt to use the JDTClassNode will find it is no longer backed by a valid resolver and the NPE will occur.

The proper solution is for Enum not to be a constant like this, but fixing that would disturb a lot of code. The more straightforward option is to ensure the component pieces of Enum that get resolved are not JDTClassNodes but instead simple ClassNodes. This isn't so heinous because these are just Class and String, both of which already exist as constants in ClassHelper.

The test suite has been modified to include the necessary extra test that refers to Enum in a basic way, before the test that runs using CompileStatic which leads to the NPE. With the change proposed in the previous paragraph the test runs fine. Change is in JDTClassNodeBuilder.configureClass().

Comment by Andy Clement [ 19/Dec/12 ]

fix committed.





[GRECLIPSE-1520] ClassNotFoundException: org.slf4j.Logger Created: 20/Oct/12  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Erwin Mueller Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_09-icedtea"
OpenJDK Runtime Environment (fedora-2.3.3.fc17-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)


Number of attachments : 0

 Description   

Hello, I have Eclise Indigo running and I did an Update of all components and now I get the below described Exception with the @Slf4j AST annotation in my tests.

Before I had:
Groovy Compiler 2.0 Feature 2.7.0.xx-20120703-1400-e42-RELEASE
Groovy-Eclipse Feature 2.7.0.xx-20120703-1400-e42-RELEASE
Groovy-Eclipse M2E integration 2.7.0.xx-20120703-1400-e42-RELEASE
m2e - Maven Integration for Eclipse 1.1.0.20120530-0009

With the update I have now:
Groovy Compiler 2.0 Feature 2.7.1.xx-20120921-2000-e42RELEASE
Groovy-Eclipse Feature 2.7.1.xx-20120921-2000-e42RELEASE
Groovy-Eclipse M2E integration 2.7.1.xx-20120921-2000-e42RELEASE
m2e - Maven Integration for Eclipse 1.2.0.20120903-1050

I have Slf4j in the maven dependencies, and if I run mvn clean test, it will compile and test successfully.

Exception:
<----
Description Resource Path Location Type
General error during semantic analysis: null

groovy.lang.GroovyRuntimeException: null
at org.codehaus.groovy.transform.LogASTTransformation$AbstractLoggingStrategy.classNode(LogASTTransformation.java:235)
at groovy.util.logging.Slf4j$Slf4jLoggingStrategy.addLoggerFieldToClass(Slf4j.java:70)
at org.codehaus.groovy.transform.LogASTTransformation$1.visitClass(LogASTTransformation.java:91)
at org.codehaus.groovy.transform.LogASTTransformation.visit(LogASTTransformation.java:136)
at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1994)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:827)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.ClassNotFoundException: org.slf4j.Logger
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:648)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:758)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:746)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.codehaus.groovy.transform.LogASTTransformation$AbstractLoggingStrategy.classNode(LogASTTransformation.java:233)
... 14 more
RunCsvProjectTest.groovy /fdsanalysiscli-csvproject/src/test/groovy/com/anrisoftware/fdsanalysis/project/csv line 0 Java Problem
---->



 Comments   
Comment by Andrew Eisenberg [ 20/Oct/12 ]

Works for me on the latest snapshot. If you are still getting problems, please paste the exact code snippet that causes the problem.

Comment by Andrew Eisenberg [ 24/Apr/13 ]

No response for a while. Please comment if you continue to have problems and include a snippet to reproduce.





[GRECLIPSE-1519] Intermittent hang when entering/editing groovy code Created: 12/Oct/12  Updated: 28/Aug/13  Resolved: 19/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Mauro Zallocco Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: Text File another.log     Text File .bak_1.log     Text File .bak_2.log     Text File .bak_3.log     Text File .log     Text File logCopy2.log     Text File logCopy3.log     Text File logCopy4.log     Text File logCopy5.log     Text File logCopy.log     Text File trace.txt    
Issue Links:
Related
is related to GRECLIPSE-1468 NPE thrown on new Groovy class wizard... Resolved
dependent
is depended upon by GRECLIPSE-1433 Intermittent editor error when editin... Resolved
is depended upon by GRECLIPSE-1452 Save Failed with AssertionFailedExcep... Resolved
Number of attachments : 11

 Description   

This may be related to GRECLIPSE-1433, and GRECLIPSE-1452.
I am entering and editing the following groovy source file and intermittently getting assertion failures on saving the file and at other times when working on something else then coming back to eclipse I notice a failure.

I upgraded to 2.7.2.xx-20121011-1000-e42 yesterday, have been upgrading frequently, seems not to have helped.

Here is the source I was entering.

package sasLasr

import java.util.StringTokenizer;

class PC {
    int i = 0
    
    class Pair {
        String x,y
        Pair readPair(String s, int from) {
            
        }
    }
    
    class Pairs {
        ArrayList<Pair> pairs
        Pairs readPairs(String s, int from) {
            return null
        }
    }
    
    class ParseData {
        int i = 0
        def result = null
        boolean ok = true
    }
    
    class MZ_X extends StringTokenizer {
        String excludeDelim = ""
        MZ_X(String str, String delim, String excludeDelim) {
            super(str, delim, true)
            this.excludeDelim = excludeDelim
        }
        
        @Override
        public String nextToken() {
            String result = super.nextToken()
            while (result == excludeDelim && hasMoreElements()) {
                result = super.nextToken()
            }
            if (result == excludeDelim) {
                result = ""
            }
            return result
        }
    }
    
    ParseData readWord(String s, int from) {
          
    }
    
    def parse(String s) {
        String word = readWord(s, 0).result
        if (word == "records") {
            //skip("=")
        }
    }
}

Attached are the .log files.
Most recent is .log then .bak_3.log, .bak_2.log, and .bak_1.log is the oldest.



 Comments   
Comment by Mauro Zallocco [ 12/Oct/12 ]

Running:
Eclipse IDE version Juno Service Release 1, build id: 20121004-1855

Comment by Andrew Eisenberg [ 12/Oct/12 ]

This does indeed look like some of those earlier bugs. Trying to reproduce, but since this is a race condition of some sort, I don't think it will be easy to.

Are you using any save actions? Eg- format on save, organize imports on save?

Comment by Mauro Zallocco [ 13/Oct/12 ]

No, not using any save actions.

Comment by Mauro Zallocco [ 13/Oct/12 ]

I have other groovy files, this file is the only one that exhibits this behavior. This being the only file with several nested classes.

On one occasion I was doing a code completion on hasMoreElements (I think it was that one), I got a popup indicating that the completion operation failed, after which I could not save the file.

Also it seems that if I maximize the code window, I dont get the problem.
I will update if I see the problem in maximized mode.
It was occurring every 20-30 min.

Comment by Andrew Eisenberg [ 18/Oct/12 ]

I'm linking this issue to GRECLIPSE-1468. The underlying problem of that issue was looking for inner classes that we know don't exist was causing problems. I haven't delved into the code yet, but I'm guessing that there is further work to do with inner classes.

Comment by Andrew Eisenberg [ 19/Oct/12 ]

I have spent hours trying to find a way that this issue can be reproduced, but have come up with nothing so far.

I added something that will hopefully gather some diagnostics. When the Java source buffer is closed whilst in the middle of a reconcile (the same issue in GRECLIPSE-1468), the following message will be added to the log:

GRECIPSE-1519: Buffer should not be closed. Paste this stack trace into http://jira.codehaus.org/browse/GRECLIPSE-1519

Please upgrade to the latest nightly and keep an eye on your error log. If you have the save issues again, or if you see the log entry message above, paste whatever stack trace you find into this bug report.

If you still see the on save error, but don't see the log entry, then your problem is occurring from somewhere else and I will need to add some more log gathering.

Comment by Mauro Zallocco [ 22/Oct/12 ]

ok will do. Upgrading now.
I was entering code in full screen mode and the error occurred.
This time I noticed the delete key was having no effect. Then tried to save and over it went.
Upgrading now and will keep you posted.

Comment by Mauro Zallocco [ 22/Oct/12 ]

Looks like I have a conflicting dependency.

Cannot complete the install because of a conflicting dependency.
Software being installed: Groovy-Eclipse Feature 2.7.2.xx-20121019-2100-e37 (org.codehaus.groovy.eclipse.feature.feature.group 2.7.2.xx-20121019-2100-e37)
Software currently installed: Eclipse IDE for Java Developers 1.5.1.20121004-1506 (epp.package.java 1.5.1.20121004-1506)
Only one of the following can be installed at once:
Object Teams Development Tooling Core 3.8.1.v_OTDT_r210_201206090452 (org.eclipse.jdt.core 3.8.1.v_OTDT_r210_201206090452)
Java Development Tools Core 3.8.2.xx-20121011-1000-e42 (org.eclipse.jdt.core 3.8.2.xx-20121011-1000-e42)
Java Development Tools Core 3.7.3.v20120119-1537 (org.eclipse.jdt.core 3.7.3.v20120119-1537)
Java Development Tools Core 3.7.1.v_B76_R37x (org.eclipse.jdt.core 3.7.1.v_B76_R37x)
Object Teams Development Tooling Core 3.7.0.v_OTDT_r200_201106070730 (org.eclipse.jdt.core 3.7.0.v_OTDT_r200_201106070730)
Object Teams Development Tooling Core 3.7.3.v_OTDT_r202_201202051448 (org.eclipse.jdt.core 3.7.3.v_OTDT_r202_201202051448)
Java Development Tools Core 3.6.0.v_A58 (org.eclipse.jdt.core 3.6.0.v_A58)
Object Teams Development Tooling Core 3.7.1.v_OTDT_r201_201109101025 (org.eclipse.jdt.core 3.7.1.v_OTDT_r201_201109101025)
Java Development Tools Core 3.7.3.xx-20121019-2100-e37 (org.eclipse.jdt.core 3.7.3.xx-20121019-2100-e37)
Java Development Tools Core 3.8.2.xx-20121013-1100-e42 (org.eclipse.jdt.core 3.8.2.xx-20121013-1100-e42)
Java Development Tools Core 3.7.0.v_B61 (org.eclipse.jdt.core 3.7.0.v_B61)
Java Development Tools Core 3.8.1.v20120531-0637 (org.eclipse.jdt.core 3.8.1.v20120531-0637)
Object Teams Development Tooling Core 3.8.2.v_OTDT_r211_201209011847 (org.eclipse.jdt.core 3.8.2.v_OTDT_r211_201209011847)
Java Development Tools Core 3.8.2.v20120814-155456 (org.eclipse.jdt.core 3.8.2.v20120814-155456)
Java Development Tools Core 3.7.3.xx-20120921-2000-e37RELEASE (org.eclipse.jdt.core 3.7.3.xx-20120921-2000-e37RELEASE)
Java Development Tools Core 3.6.1.v_A68_R36x (org.eclipse.jdt.core 3.6.1.v_A68_R36x)
Java Development Tools Core 3.6.2.v_A76_R36x (org.eclipse.jdt.core 3.6.2.v_A76_R36x)
Cannot satisfy dependency:
From: Eclipse IDE for Java Developers 1.5.1.20121004-1506 (epp.package.java 1.5.1.20121004-1506)
To: org.eclipse.epp.package.java.feature.feature.group [1.5.1.20121004-1506]
Cannot satisfy dependency:
From: Groovy-Eclipse Feature 2.7.2.xx-20121019-2100-e37 (org.codehaus.groovy.eclipse.feature.feature.group 2.7.2.xx-20121019-2100-e37)
To: org.codehaus.groovy.jdt.patch.feature.group [2.7.1.xx-20121019-2100-e37]
Cannot satisfy dependency:
From: EPP Java Package 1.5.1.20121004-1506 (org.eclipse.epp.package.java.feature.feature.group 1.5.1.20121004-1506)
To: org.eclipse.jdt.feature.group 0.0.0
Cannot satisfy dependency:
From: EPP Java Package 1.5.1.20121004-1506 (org.eclipse.epp.package.java.feature.feature.group 1.5.1.20121004-1506)
To: org.eclipse.recommenders.feature.rcp.feature.group 0.0.0
Cannot satisfy dependency:
From: Code Recommenders: Intelligent Completion Extension for Eclipse 3.8 1.0.0.v20120612-2305-b156 (org.eclipse.recommenders.completion.rcp.e38 1.0.0.v20120612-2305-b156)
To: bundle org.eclipse.jdt.core [3.8.0,3.9.0)
Cannot satisfy dependency:
From: Code Recommenders: Intelligent Completion Extension for Eclipse 3.8 1.0.0.v20120914-1432-b175 (org.eclipse.recommenders.completion.rcp.e38 1.0.0.v20120914-1432-b175)
To: bundle org.eclipse.jdt.core 3.8.0
Cannot satisfy dependency:
From: Code Recommenders: Chain Completion 1.0.0.v20120612-2305-b156 (org.eclipse.recommenders.feature.completion.rcp.chain.feature.group 1.0.0.v20120612-2305-b156)
To: org.eclipse.recommenders.completion.rcp.e38 [1.0.0.v20120612-2305-b156]
Cannot satisfy dependency:
From: Code Recommenders: Chain Completion 1.0.0.v20120914-1432-b175 (org.eclipse.recommenders.feature.completion.rcp.chain.feature.group 1.0.0.v20120914-1432-b175)
To: org.eclipse.recommenders.completion.rcp.e38 [1.0.0.v20120914-1432-b175]
Cannot satisfy dependency:
From: Code Recommenders Developer Tools 1.0.0.v20120612-2305-b156 (org.eclipse.recommenders.feature.rcp.feature.group 1.0.0.v20120612-2305-b156)
To: org.eclipse.recommenders.feature.completion.rcp.chain.feature.group [1.0.0.v20120612-2305-b156]
Cannot satisfy dependency:
From: Code Recommenders Developer Tools 1.0.0.v20120914-1432-b175 (org.eclipse.recommenders.feature.rcp.feature.group 1.0.0.v20120914-1432-b175)
To: org.eclipse.recommenders.feature.completion.rcp.chain.feature.group [1.0.0.v20120914-1432-b175]
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.7.1.xx-20121019-2100-e37 Eclipse Java Development Tools 3.6.0.v20100526-0800-7z8XFUJFMTfCWGoVuHImpms9H155 (org.eclipse.jdt.feature.group 3.6.0.v20100526-0800-7z8XFUJFMTfCWGoVuHImpms9H155)
To: org.eclipse.jdt.core [3.7.3.xx-20121019-2100-e37]
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.7.1.xx-20121019-2100-e37 Eclipse Java Development Tools 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH (org.eclipse.jdt.feature.group 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH)
To: org.eclipse.jdt.core [3.7.3.xx-20121019-2100-e37]
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.7.1.xx-20121019-2100-e37 Eclipse Java Development Tools 3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F (org.eclipse.jdt.feature.group 3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F)
To: org.eclipse.jdt.core [3.7.3.xx-20121019-2100-e37]
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.7.1.xx-20121019-2100-e37 Eclipse Java Development Tools 3.7.0.v20110520-0800-7z8gFchFMTdFYKuLqBLqRja9B15B (org.eclipse.jdt.feature.group 3.7.0.v20110520-0800-7z8gFchFMTdFYKuLqBLqRja9B15B)
To: org.eclipse.jdt.core [3.7.3.xx-20121019-2100-e37]
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.7.1.xx-20121019-2100-e37 Eclipse Java Development Tools 3.7.1.r371_v20110810-0800-7z8gFcoFMLfTabvKsR5Qm9rBGEBK (org.eclipse.jdt.feature.group 3.7.1.r371_v20110810-0800-7z8gFcoFMLfTabvKsR5Qm9rBGEBK)
To: org.eclipse.jdt.core [3.7.3.xx-20121019-2100-e37]
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.7.1.xx-20121019-2100-e37 Eclipse Java Development Tools 3.7.2.v20120120-1414-7z8gFcuFMP7BW5XTz0jLTnz0l9B1 (org.eclipse.jdt.feature.group 3.7.2.v20120120-1414-7z8gFcuFMP7BW5XTz0jLTnz0l9B1)
To: org.eclipse.jdt.core [3.7.3.xx-20121019-2100-e37]
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.7.1.xx-20121019-2100-e37 Eclipse Java Development Tools 3.8.0.v20120525-1249-8-8nFqlFNOfwKDRGz-pXLdGxEM83 (org.eclipse.jdt.feature.group 3.8.0.v20120525-1249-8-8nFqlFNOfwKDRGz-pXLdGxEM83)
To: org.eclipse.jdt.core [3.7.3.xx-20121019-2100-e37]
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.7.1.xx-20121019-2100-e37 Eclipse Java Development Tools 3.8.1.v20120814-104540-8-8nFqpFNOfwKDRVz-tXOcL5d_83 (org.eclipse.jdt.feature.group 3.8.1.v20120814-104540-8-8nFqpFNOfwKDRVz-tXOcL5d_83)
To: org.eclipse.jdt.core [3.7.3.xx-20121019-2100-e37]

Comment by Andrew Eisenberg [ 22/Oct/12 ]

Looks like a mixed up update site. Are you running on e37 or e42 (which includes e38)? Make sure that the update site suffix matches your eclipse version.

Comment by Mauro Zallocco [ 22/Oct/12 ]

e42.
Looks like I had e37 on my update sites list. Have removed those.
Much better now.

Comment by Andrew Eisenberg [ 22/Oct/12 ]

Please post the version qualifier of the installed groovy-eclipse. I just want to make sure that it is the latest. We had a problem that the latest build of the e42 branch wasn't pushed out (this is the build with the fixes in it). I pushed it out myself about an hour and a half ago.

Comment by Mauro Zallocco [ 22/Oct/12 ]

2.7.2.xx-20121013-1100-e42, groovy.eclipse.feature, groovy17.feature, groovy20.feature, groovy.jdt.patch, groovy18.feature.

Got another failure.
Attaching the log file logCopy.log

Comment by Mauro Zallocco [ 22/Oct/12 ]

Just checked again for updates.
Pulled 2.7.2.xx-20121019-2100-e42.

Comment by Andrew Eisenberg [ 22/Oct/12 ]

Sorry for the confusion. Let's hope that this new version shows something interesting.

Looked at your log file, and it is likely the same problem as before. However, the stack traces are not providing any more information about how the problem started.

Comment by Mauro Zallocco [ 23/Oct/12 ]

ok another failed to save.
See if this log file is more informative.
logCopy2.log

Comment by Andrew Eisenberg [ 23/Oct/12 ]

Uggggh. Sorry to say that the stack trace didn't show what I was hoping it would. Let me think a bit more on this. I'll try to add a bit more logging information in other places.

At least we know a bit more, that this problem is unrelated to the earlier problem that we were having. Thanks for your help with this.

Comment by Davide Cavestro [ 25/Oct/12 ]

Attaching another.log for my workspace, where I experimented some problems after a huge update due to the fact that we enabled at project level save actions with code reformat, organizing imports and so on. We intended to do that only for java sources, but it see even the groovy editor does the same.
BTW when I saved some changes to a groovy file eclipse complained some problems relative to a spurious save from one of the save actions. Then I disabled save actions on the project and I start to see on the log error messages inviting to attach the log to this issue (you will see some errors relative to the huge update I mentioned above... I guess you should ignore them). I hope this stacktraces give you more info than Mauro's ones.

Comment by Mauro Zallocco [ 25/Oct/12 ]

Just updated plugins.
What I'm seeing is that the save button now leaves the window dirty.
Presumably before it was just failing.
Some interesting stack traces are being printed.
See logCopy3.log.

Comment by Andrew Eisenberg [ 25/Oct/12 ]

Ahhh....yes. This is the logging that I added. Quite helpful. I can now see what is causing the editor to lose its buffer. I will be able to dig around and see if this leads to a solution. Thanks for posting it.

Comment by Mauro Zallocco [ 31/Oct/12 ]

Another one for good measure.
logCopy4.log

Comment by Mauro Zallocco [ 02/Nov/12 ]

Updated to 2.7.2.xx-20121031-1500-e42.
Got another set of failures.
See attached logCopy5.log.

Comment by Andrew Eisenberg [ 02/Nov/12 ]

I've been trying to track this down and the initial failure is still not being captured by the stack traces I added.

Is there any way that you can avoid using inner classes in the affected files? Or, is it happening in files that do not have inner classes?

Comment by Mauro Zallocco [ 04/Nov/12 ]

I have converted all inner classes to separate class files.
I'll post if I see anything.

Comment by Mauro Zallocco [ 26/Nov/12 ]

Just to let you know, after converting inner classes to separate class files, I have not seen any of these issues.
Have not upgraded since 04/Nov.

Comment by Andrew Eisenberg [ 26/Nov/12 ]

Thanks for confirmation on the workaround. I have not been able to determine a fix for this yet.

Comment by Andrew Eisenberg [ 07/Dec/12 ]

Alex, thanks for the stack trace. I am looking at this now. Does your test class use any inner classes?

Comment by Roland Plass [ 12/Dec/12 ]

-Cannot save file after Error appears
-Class embeds an inner class
-often goes hand in hand with Autocompletion Errors in Errorlog [Exception when creating groovy completion proposal]

eclipse.buildId=I20120608-1400
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Framework arguments: -clear
Command-line arguments: -os linux -ws gtk -arch x86_64 -clear

This is a continuation of log file /data/workspace/.metadata/.bak_8.log
Created Time: 2012-12-12 15:25:06.012

Error
Wed Dec 12 15:30:17 CET 2012
GRECIPSE-1519: Buffer should not be closed. Paste this stack trace into http://jira.codehaus.org/browse/GRECLIPSE-1519

java.lang.RuntimeException
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:159)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:388)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:318)
at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:112)
at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

Comment by Andrew Eisenberg [ 12/Dec/12 ]

The best information that we have now is that this occurs when there are inner classes in the file. If you move the classes to top level, the problem should go away.

Comment by Jeff Brown [ 17/Dec/12 ]

I am seeing this problem in GGTS right now:

java.lang.RuntimeException
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
	at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:159)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:388)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:318)
	at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
	at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:112)
	at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
	at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
Comment by Eirik Lygre [ 23/Dec/12 ]

My class also has inner classes ... but not for long . It might be worth noting that there are two classes in the system which has an inner class with the same name.

eclipse.buildId=M20120914-1800
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product

Error
Sun Dec 23 14:21:13 CET 2012
GRECIPSE-1519: Buffer should not be closed.  Paste this stack trace into http://jira.codehaus.org/browse/GRECLIPSE-1519

java.lang.RuntimeException
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
	at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:120)
	at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:294)
	at org.eclipse.jdt.internal.core.CancelableNameEnvironment.findType(CancelableNameEnvironment.java:45)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:145)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2554)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitScope.lookupClassNodeForSource(GroovyCompilationUnitScope.java:233)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromCompileUnit(JDTResolver.java:173)
	at org.codehaus.groovy.control.ResolveVisitor.resolveNestedClass(ResolveVisitor.java:388)
	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:361)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:368)
	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:318)
	at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:281)
	at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:310)
	at org.codehaus.groovy.control.ResolveVisitor.transformVariableExpression(ResolveVisitor.java:1114)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:877)
	at org.codehaus.groovy.control.ResolveVisitor.transformDeclarationExpression(ResolveVisitor.java:1244)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:881)
	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1511)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:50)
	at org.codehaus.groovy.control.ResolveVisitor.visitConstructorOrMethod(ResolveVisitor.java:225)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1181)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1447)
	at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:200)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:554)
	at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:677)
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:940)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:612)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:561)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:2015)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:980)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:201)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:344)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
	at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1100)
	at org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:60)
	at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:435)
	at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1231)
	at org.eclipse.jdt.internal.corext.util.JavaModelUtil.reconcile(JavaModelUtil.java:594)
	at org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:283)
	at org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:199)
	at org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:183)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$5$1.getSelection(JavaEditor.java:2247)
	at org.eclipse.ui.internal.WorkbenchPage.updateShowInSources(WorkbenchPage.java:354)
	at org.eclipse.ui.internal.e4.compatibility.SelectionService$1.selectionChanged(SelectionService.java:76)
	at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$2.run(SelectionAggregator.java:111)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.SelectionAggregator.notifyListeners(SelectionAggregator.java:109)
	at org.eclipse.e4.ui.internal.workbench.SelectionAggregator.access$4(SelectionAggregator.java:106)
	at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$4$1.run(SelectionAggregator.java:163)
	at org.eclipse.e4.core.contexts.RunAndTrack.runExternalCode(RunAndTrack.java:53)
	at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$4.changed(SelectionAggregator.java:161)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:110)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:318)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.set(EclipseContext.java:332)
	at org.eclipse.e4.ui.internal.workbench.SelectionServiceImpl.setSelection(SelectionServiceImpl.java:30)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.selectionChanged(CompatibilityPart.java:420)
	at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2755)
	at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2703)
	at org.eclipse.jface.text.TextViewer$5.run(TextViewer.java:2682)
	at org.eclipse.swt.widgets.Display.runTimer(Display.java:4270)
	at org.eclipse.swt.widgets.Display.messageProc(Display.java:3357)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1029)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:923)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

and

eclipse.buildId=M20120914-1800
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product
Comment by Thomas Weissinger [ 14/Jan/13 ]

You asked for it, here it is:

java.lang.RuntimeException
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:120)
at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:294)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:145)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2554)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitScope.lookupClassNodeForSource(GroovyCompilationUnitScope.java:233)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromCompileUnit(JDTResolver.java:173)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:330)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:368)
at org.codehaus.groovy.control.ResolveVisitor.resolveFromStaticInnerClasses(ResolveVisitor.java:506)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromStaticInnerClasses(JDTResolver.java:265)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:332)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:368)
at org.codehaus.groovy.control.ResolveVisitor.resolveFromModule(ResolveVisitor.java:742)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromModule(JDTResolver.java:147)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:329)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:368)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:285)
at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:948)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:809)
at org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:49)
at org.codehaus.groovy.ast.expr.ArgumentListExpression.transformExpression(ArgumentListExpression.java:67)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:826)
at org.codehaus.groovy.control.ResolveVisitor.transformMethodCallExpression(ResolveVisitor.java:1156)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:817)
at org.codehaus.groovy.control.ResolveVisitor.transformDeclarationExpression(ResolveVisitor.java:1183)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:811)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1443)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitTryCatchFinally(CodeVisitorSupport.java:82)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitTryCatchFinally(ClassCodeVisitorSupport.java:244)
at org.codehaus.groovy.ast.stmt.TryCatchStatement.visit(TryCatchStatement.java:42)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1443)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:50)
at org.codehaus.groovy.control.ResolveVisitor.visitConstructorOrMethod(ResolveVisitor.java:192)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1176)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1379)
at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:167)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:554)
at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:691)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:993)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:625)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:574)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:2015)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:797)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:594)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyBuilder.buildSupertypes(HierarchyBuilder.java:126)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:135)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:300)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1263)
at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:739)
at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:691)
at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:142)
at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:94)
at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getMethodOverrideTester(SuperTypeHierarchyCache.java:103)
at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.getOverrideIndicators(OverrideIndicatorLabelDecorator.java:171)
at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.computeAdornmentFlags(OverrideIndicatorLabelDecorator.java:136)
at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.decorate(OverrideIndicatorLabelDecorator.java:273)
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:269)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:371)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:331)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Session data:

eclipse.buildId=I20120608-1400
java.version=1.6.0_37
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product -keyring /Users/tweissin/.eclipse_keyring -showlocation
Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/tweissin/.eclipse_keyring -showlocation

This is a continuation of log file /Users/tweissin/Documents/workspace4/.metadata/.bak_0.log
Created Time: 2013-01-14 16:15:25.176

Comment by Andy Clement [ 18/Jan/13 ]

Another stack trace seen by Jeff. Andrew, we should take a look at this together - maybe we can treat inner classes differently in some way to address it.

java.lang.RuntimeException
    at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
    at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
    at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
    at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:159)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:388)
    at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:318)
    at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
    at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
    at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
    at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
    at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:112)
    at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
    at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
[13-01-18 12:50:45 PM] Jeff Brown: GRECIPSE-1519: Buffer should not be closed.  Paste this stack trace into http://jira.codehaus.org/browse/GRECLIPSE-1519
Comment by Andrew Eisenberg [ 21/Jan/13 ]

I have done some more looking into this bug and I was able to find a few more places where looking for inner classes could theoretically cause the underlying buffer to be closed. I still cannot reproduce, but these few hot spots might contribute to the problem.

I made a few changes with how the groovy compiler searches for inner classes to avoid the hotspots (and improve performance). All of our unit tests are still passing, but these are some scary changes.

Can someone who is affected by this bug update to the latest snapshot build and try this out?

Comment by GubeSpam [ 29/Jan/13 ]

Got this error: GRECIPSE-1519: Buffer should not be closed.

This occurred while editing a class that has a private static class inside it.

Env: STS 3.0 / Groovy-Eclipse plugin 2.8.0

eclipse.buildId=3.0.0.201208091018-RELEASE-e42
java.version=1.7.0_06
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.springsource.sts.ide
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.springsource.sts.ide
java.lang.RuntimeException
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
	at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:159)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:388)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:318)
	at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
	at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:112)
	at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
	at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
Comment by Andrew Eisenberg [ 29/Jan/13 ]

@GubeSpam, just to be sure, are you running with the latest nightly build of groovy-eclipse?

Comment by Mauro Zallocco [ 02/Feb/13 ]

Downloaded new Eclipse and installed the snapshot several days ago.
Added some nested classes.
No trouble saving files.
All working.

Went back to the original eclipse with the older snapshot, induced the save failure by adding a simple method to the nested class.
Tried the exact same thing with the new snapshot and it held up.
Was able to save the file.

Looks very promising.

Comment by Andrew Eisenberg [ 02/Feb/13 ]

@Mauro Zallocco, thanks for the feedback. I will keep this open for a bit longer to get some more comments, but this is promising.

Comment by Richard Hansen [ 06/Feb/13 ]

Eclipse Juno, Groovy Eclipse - 2.8.0.xx-20130205-1700-e42, Windows 7

eclipse.buildId=M20120914-1800
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments: -Declipse.refreshBundles=true -product org.eclipse.epp.package.java.product
Command-line arguments: -Declipse.refreshBundles=true -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product

This is a continuation of log file C:\proj\.metadata\.bak_0.log
Created Time: 2013-02-06 11:02:55.391

Error
Wed Feb 06 13:15:47 CST 2013
GRECIPSE-1519: Buffer should not be closed. Paste this stack trace into http://jira.codehaus.org/browse/GRECLIPSE-1519

java.lang.RuntimeException
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:159)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:398)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:328)
at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:112)
at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

eclipse.buildId=M20120914-1800
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments: -Declipse.refreshBundles=true -product org.eclipse.epp.package.java.product
Command-line arguments: -Declipse.refreshBundles=true -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product

This is a continuation of log file C:\proj\.metadata\.bak_0.log
Created Time: 2013-02-06 11:02:55.391

Error
Wed Feb 06 13:15:44 CST 2013
GRECIPSE-1519: Buffer should not be closed. Paste this stack trace into http://jira.codehaus.org/browse/GRECLIPSE-1519

java.lang.RuntimeException
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:120)
at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:294)
at org.eclipse.jdt.internal.core.CancelableNameEnvironment.findType(CancelableNameEnvironment.java:45)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:145)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2554)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitScope.lookupClassNodeForSource(GroovyCompilationUnitScope.java:246)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromCompileUnit(JDTResolver.java:173)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:364)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:379)
at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:1057)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:910)
at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:1031)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:910)
at org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:49)
at org.codehaus.groovy.ast.expr.ArgumentListExpression.transformExpression(ArgumentListExpression.java:67)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:925)
at org.codehaus.groovy.control.ResolveVisitor.transformMethodCallExpression(ResolveVisitor.java:1255)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:916)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1542)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:50)
at org.codehaus.groovy.control.ResolveVisitor.visitConstructorOrMethod(ResolveVisitor.java:226)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1181)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1478)
at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:201)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:561)
at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:677)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:940)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:612)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:561)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:2015)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:980)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:201)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:344)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1100)
at org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:60)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:435)
at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1231)
at org.eclipse.jdt.internal.corext.util.JavaModelUtil.reconcile(JavaModelUtil.java:594)
at org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:283)
at org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:199)
at org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:183)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$5$1.getSelection(JavaEditor.java:2247)
at org.eclipse.ui.internal.WorkbenchPage.updateShowInSources(WorkbenchPage.java:354)
at org.eclipse.ui.internal.e4.compatibility.SelectionService$1.selectionChanged(SelectionService.java:76)
at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$2.run(SelectionAggregator.java:111)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.e4.ui.internal.workbench.SelectionAggregator.notifyListeners(SelectionAggregator.java:109)
at org.eclipse.e4.ui.internal.workbench.SelectionAggregator.access$4(SelectionAggregator.java:106)
at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$4$1.run(SelectionAggregator.java:163)
at org.eclipse.e4.core.contexts.RunAndTrack.runExternalCode(RunAndTrack.java:53)
at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$4.changed(SelectionAggregator.java:161)
at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:110)
at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:318)
at org.eclipse.e4.core.internal.contexts.EclipseContext.set(EclipseContext.java:332)
at org.eclipse.e4.ui.internal.workbench.SelectionServiceImpl.setSelection(SelectionServiceImpl.java:30)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.selectionChanged(CompatibilityPart.java:420)
at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2755)
at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2703)
at org.eclipse.jface.text.TextViewer$5.run(TextViewer.java:2682)
at org.eclipse.swt.widgets.Display.runTimer(Display.java:4270)
at org.eclipse.swt.widgets.Display.messageProc(Display.java:3357)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1029)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:923)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

Comment by perriman [ 08/Feb/13 ]

This problems is very important for us, Any workarround?

Comment by Andrew Eisenberg [ 08/Feb/13 ]

@perriman, two possibilities. I think this problem is fixed with the latest nightly build, although Richard's comment seems to point otherwise.

I know that this is caused by inner classes. So, if there is a file with inner classes, you can try moving them to top level classes. But, better to upgrade to the latest nightly snapshot.

Comment by Andrew Eisenberg [ 19/Mar/13 ]

@perriman, any update here? Are you able to reproduce on the latest nightly build?

Comment by Andrew Eisenberg [ 19/Mar/13 ]

I am pretty sure that this bug is now fixed. But, please comment here if you are still seeing a problem on the latest nightly build.

Comment by guillaume [ 28/Aug/13 ]

I saw this stack on 2.8.0

java.lang.RuntimeException
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:544)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:120)
at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:294)
at org.eclipse.jdt.internal.core.CancelableNameEnvironment.findType(CancelableNameEnvironment.java:45)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:145)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2554)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitScope.lookupClassNodeForSource(GroovyCompilationUnitScope.java:246)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromCompileUnit(JDTResolver.java:173)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:330)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:379)
at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:988)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:839)
at org.codehaus.groovy.control.ResolveVisitor.transformBinaryExpression(ResolveVisitor.java:1140)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:845)
at org.codehaus.groovy.control.ResolveVisitor.transformBinaryExpression(ResolveVisitor.java:1086)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:845)
at org.codehaus.groovy.control.ResolveVisitor.transformDeclarationExpression(ResolveVisitor.java:1213)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:841)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:36)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1473)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:50)
at org.codehaus.groovy.control.ResolveVisitor.visitConstructorOrMethod(ResolveVisitor.java:192)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1177)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1409)
at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:167)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:561)
at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:691)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:993)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:625)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:574)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:2015)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:980)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody0(CompilationUnitProblemFinder.java:201)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody1$advice(CompilationUnitProblemFinder.java:244)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:1)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:325)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:159)
at org.grails.ide.eclipse.editor.groovy.elements.GrailsProject.getPrimaryType(GrailsProject.java:175)
at org.grails.ide.eclipse.editor.groovy.elements.GrailsProject.internalFindGrailsElementsForProject(GrailsProject.java:517)
at org.grails.ide.eclipse.editor.groovy.elements.GrailsProject.findAllServices(GrailsProject.java:476)
at org.grails.ide.eclipse.editor.groovy.types.PerProjectServiceCache.ensureInitialized(PerProjectServiceCache.java:108)
at org.grails.ide.eclipse.editor.groovy.types.PerProjectServiceCache.findServicesFor(PerProjectServiceCache.java:93)
at org.grails.ide.eclipse.editor.groovy.elements.AbstractGrailsElement.populateInjectedServices(AbstractGrailsElement.java:148)
at org.grails.ide.eclipse.editor.groovy.elements.ServiceClass.initializeTypeLookup(ServiceClass.java:43)
at org.grails.ide.eclipse.editor.groovy.types.GrailsTypeLookup.initialize(GrailsTypeLookup.java:100)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:319)
at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.initialReconcile(JavaCompositeReconcilingStrategy.java:144)
at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105)
at org.eclipse.jdt.internal.ui.text.JavaReconciler.initialProcess(JavaReconciler.java:406)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173)





[GRECLIPSE-1518] Can't find the p2 repo for groovy eclipse 2.7.0 Created: 11/Oct/12  Updated: 08/Nov/12  Resolved: 08/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Pascal Rapicault Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I'm putting together an eclipse distro based on Eclipse 3.8 and I'm looking for a p2 repo containing the p2 repo containing eclipse 2.7.0 but I can't seem to find it. Where is it hidden?



 Comments   
Comment by Andrew Eisenberg [ 11/Oct/12 ]

Any reason for 2.7.0? 2.7.1 is now the most recent release.

Repo is here:
http://dist.springsource.org/release/GRECLIPSE/e4.2/

We don't tend to keep the old repos around. We have an archive available of 2.7.0 and if there's a need, I can place it in a permanent location.

Comment by Pascal Rapicault [ 08/Nov/12 ]

Some of our users (I'm at the moment with Ericsson) need to gain access to the older versions because they understood that 2.7.1 implied 3.8.1.
And from a p2 citizenship point of view, it is good to keep them around so people can revert back their install or find older versions of the bytes if they have a build that pull in this particular version.

All that said, my needs are now satisfied so we can close this bug.
To avoid further questions, I would putting a link to the download on your web site.

Comment by Andrew Eisenberg [ 08/Nov/12 ]

Thanks for the feedback. For future releases, I'll be sure to keep the older releases available. I may even backdate and make older releases available as well.





[GRECLIPSE-1517] General error during instruction selection: EmptyStackException Created: 11/Oct/12  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Critical
Reporter: Mauro Molinari Assignee: Andy Clement
Resolution: Cannot Reproduce  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I don't know if this is a GRECLIPSE or Groovy bug. However I have a problem on which a Groovy class i marked at line 0 with the following problem:

General error during instruction selection: java.util.EmptyStackException java.util.EmptyStackException at 
 java.util.Stack.peek(Unknown Source) at 
 org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createClassNode(JDTResolver.java:556) at 
 org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createJDTClassNode(JDTResolver.java:482) at 
 org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.convertToClassNode(JDTResolver.java:470) at 
 org.codehaus.jdt.groovy.internal.compiler.ast.LazyGenericsType.ensureInitialized(LazyGenericsType.java:150) at 
 org.codehaus.jdt.groovy.internal.compiler.ast.LazyGenericsType.getType(LazyGenericsType.java:47) at 
 org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.fullyResolve(StaticTypeCheckingVisitor.java:2838) 
 at 
 org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.fullyResolveType(StaticTypeCheckingVisitor.java:
 2862) at 
 org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.typeCheckMethodsWithGenerics(StaticTypeChecki
 ngVisitor.java:2991) at 
 org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisi
 tor.java:1877) at 
 org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.ja
 va:205) at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:67) at 
 org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69) at 
 org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209) at 
 org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40) at 
 org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35) at 
 org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179) at 
 org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69) at 
 org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102) at 
 org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113) 
 at 
 org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisi
 tor.java:1276) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:
 124) at 
 org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.ja
 va:1517) at 
 org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:1491) 
 at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(StaticCompilationVisitor.java:117) at 
 org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:68) at 
 org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147) at 
 org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220) at 
 org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191) at 
 org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623) at 
 org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601) at 
 org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578) at 
 org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompi
 lationUnitDeclaration.java:171) at 
 org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilat
 ionUnitDeclaration.java:1534) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838) at 
 org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at 
 java.lang.Thread.run(Unknown Source)

The result is that the compilation and indexing of Groovy classes stops (it seems like it's performed only on few classes).

It's not easy to tell you what code is causing this, because:

  • the error is marked on a class that is neither using static type checking nor extending another class that does, so I fear the location of the error mark is not significant for the problem
  • the full codebase is big and proprietary

Is there any way to understand what's going on? At the moment I'm stuck and I don't know what to do (I may try to hunt for static type checking annotations in the codebase and remove all of them...).

Using GRECLIPSE 2.7.1.xx-20120921-2000-e42RELEASE.



 Comments   
Comment by Mauro Molinari [ 11/Oct/12 ]

Sorry for misspelling: "I have a problem on which a Groovy class i marked at line 0" should be "I have a problem on a Groovy class which is marked at line 0"...

Comment by Mauro Molinari [ 11/Oct/12 ]

I discovered I have a sibling class of the one on which the error mark is put which had a @CompileStatic annotation on a method. When I tried to remove that annotation and hit "Save", I got the following exception:

java.util.EmptyStackException
	at java.util.Stack.peek(Unknown Source)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createClassNode(JDTResolver.java:556)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createJDTClassNode(JDTResolver.java:482)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.convertToClassNode(JDTResolver.java:470)
	at org.codehaus.jdt.groovy.internal.compiler.ast.LazyGenericsType.ensureInitialized(LazyGenericsType.java:150)
	at org.codehaus.jdt.groovy.internal.compiler.ast.LazyGenericsType.getLowerBound(LazyGenericsType.java:41)
	at org.codehaus.groovy.eclipse.refactoring.actions.OrganizeGroovyImports$FindUnresolvedReferencesVisitor.handleType(OrganizeGroovyImports.java:299)
	at org.codehaus.groovy.eclipse.refactoring.actions.OrganizeGroovyImports$FindUnresolvedReferencesVisitor.visitMethod(OrganizeGroovyImports.java:170)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1174)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.eclipse.refactoring.actions.OrganizeGroovyImports$FindUnresolvedReferencesVisitor.visitClass(OrganizeGroovyImports.java:191)
	at org.codehaus.groovy.eclipse.refactoring.actions.OrganizeGroovyImports.calculateMissingImports(OrganizeGroovyImports.java:406)
	at org.codehaus.groovy.eclipse.refactoring.actions.GroovyImportsCleanUp.createFix(GroovyImportsCleanUp.java:58)
	at org.eclipse.jdt.internal.corext.fix.CleanUpRefactoring.calculateChange(CleanUpRefactoring.java:807)
	at org.codehaus.groovy.eclipse.refactoring.actions.CleanUpPostSaveListener.saved(CleanUpPostSaveListener.java:354)
	at org.codehaus.groovy.eclipse.refactoring.actions.DelegatingCleanUpPostSaveListener.saved(DelegatingCleanUpPostSaveListener.java:120)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$5.run(CompilationUnitDocumentProvider.java:1589)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.notifyPostSaveListeners(CompilationUnitDocumentProvider.java:1584)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.commitWorkingCopy(CompilationUnitDocumentProvider.java:1378)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$4.execute(CompilationUnitDocumentProvider.java:1449)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider$DocumentProviderOperation.run(TextFileDocumentProvider.java:132)
	at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
	at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
	at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
	at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:456)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument(TextFileDocumentProvider.java:772)
	at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5066)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSave(CompilationUnitEditor.java:1247)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:1301)
	at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7198)
	at org.eclipse.ui.Saveable.doSave(Saveable.java:214)
	at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:346)
	at org.eclipse.ui.internal.SaveableHelper$3.run(SaveableHelper.java:193)
	at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:274)
	at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
	at org.eclipse.ui.internal.WorkbenchWindow$13.run(WorkbenchWindow.java:1666)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1663)
	at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:282)
	at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:261)
	at org.eclipse.ui.internal.SaveableHelper.saveModels(SaveableHelper.java:204)
	at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:144)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.doSave(CompatibilityPart.java:404)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:235)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:199)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:89)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.savePart(PartServiceImpl.java:1154)
	at org.eclipse.ui.internal.WorkbenchPage.saveSaveable(WorkbenchPage.java:3459)
	at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3477)
	at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:76)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
	at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
	at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1521)
	at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640)
	at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4528)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4976)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

After this, I cleaned the project and then the error mark on the original class has gone. However, if I go to the bin folder I find that the Groovy classes have been compiled, but if I hit "Ctrl+Shift+T" the indexer seems not to find some Groovy classes yet

Comment by Andy Clement [ 28/Nov/12 ]

The stack is gone in the latest groovy eclipse so this can't happen. Something else may go wrong but the EmptyStackException can't occur.





[GRECLIPSE-1516] Internal groovy compiler error Created: 07/Oct/12  Updated: 22/Apr/13  Resolved: 22/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Morten Hindsholm Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ContainerClient.groovy     File Container.groovy    
Number of attachments : 2

 Description   
Container.groovy
class Container {
    @Delegate List list = [:].values().asList().asImmutable()
}
ContainerClient.groovy
class ContainerClient {
    def create() {
        def container = new Container()
    }
}

Eclipse reports an 'Internal groovy compiler error' in ContainerClient:
BUG! exception in phase 'semantic analysis' in source unit
'C:\projects\landscape\test\unit\ContainerClient.groovy' Pb(538)
Inconsistent classfile encountered: The undefined type parameter E is
referenced from within Container
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:949)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:612)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:561)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1994)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:827)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:662)

eclipse.buildId=3.0.0.201208091018-RELEASE-e42
Groovy-Eclipse Feature 2.7.1.xx-20120921-2000-e42RELEASE
Groovy Compiler version 1.8.6.xx-20120921-2000-e42RELEASE

If I clean the project the error goes away, but whenever I touch one
of the two classes it reappears.

The code is part of a Grails 2.1.0 project which builds OK outside Eclipse.



 Comments   
Comment by Andrew Eisenberg [ 07/Oct/12 ]

Thanks for reporting. We'll take a look at this.

Comment by Andrew Eisenberg [ 22/Apr/13 ]

Fixed now.





[GRECLIPSE-1515] CompileStatic NPE when doing the bitwise ngegation of a string Created: 05/Oct/12  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GRECLIPSE-1514 CompileStatic stack overflow issue Resolved
Number of attachments : 0

 Description   

This code:

import groovy.transform.CompileStatic;
import java.util.regex.Pattern

@CompileStatic
class C {
    void validate () {
        for (String validationKey : keySet()) {
        	String regex
        	Pattern pattern = ~regex
        }
	}
}  

NPE:

java.lang.NullPointerException
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBitwiseNegationExpression(StaticTypeCheckingVisitor.java:1174)
	at org.codehaus.groovy.ast.expr.BitwiseNegationExpression.visit(BitwiseNegationExpression.java:37)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBinaryExpression(CodeVisitorSupport.java:144)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBinaryExpression(StaticTypeCheckingVisitor.java:402)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitDeclarationExpression(CodeVisitorSupport.java:245)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitDeclarationExpression(ClassCodeVisitorSupport.java:108)
	at org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:87)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitForLoop(CodeVisitorSupport.java:41)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitForLoop(ClassCodeVisitorSupport.java:214)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitForLoop(StaticTypeCheckingVisitor.java:1105)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitForLoop(StaticCompilationVisitor.java:253)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitForLoop(StaticTypeCheckingVisitor.java:1111)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitForLoop(StaticCompilationVisitor.java:253)
	at org.codehaus.groovy.ast.stmt.ForStatement.visit(ForStatement.java:47)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1276)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:1517)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:1491)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(StaticCompilationVisitor.java:117)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1174)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:222)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:108)
	at org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:58)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1534)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:986)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:201)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:319)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
	at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1105)
	at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1085)
	at org.eclipse.jdt.internal.core.CommitWorkingCopyOperation.executeOperation(CommitWorkingCopyOperation.java:124)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
	at org.eclipse.jdt.internal.core.CompilationUnit.commitWorkingCopy(CompilationUnit.java:393)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.commitWorkingCopy(CompilationUnitDocumentProvider.java:1376)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$4.execute(CompilationUnitDocumentProvider.java:1449)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider$DocumentProviderOperation.run(TextFileDocumentProvider.java:132)
	at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
	at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
	at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
	at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:456)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument(TextFileDocumentProvider.java:772)
	at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5066)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSave(CompilationUnitEditor.java:1247)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:1301)
	at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7198)
	at org.eclipse.ui.Saveable.doSave(Saveable.java:214)
	at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:346)
	at org.eclipse.ui.internal.SaveableHelper$3.run(SaveableHelper.java:193)
	at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:274)
	at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
	at org.eclipse.ui.internal.WorkbenchWindow$13.run(WorkbenchWindow.java:1675)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1672)
	at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:282)
	at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:261)
	at org.eclipse.ui.internal.SaveableHelper.saveModels(SaveableHelper.java:204)
	at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:144)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.doSave(CompatibilityPart.java:404)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:235)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:199)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:89)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.savePart(PartServiceImpl.java:1179)
	at org.eclipse.ui.internal.WorkbenchPage.saveSaveable(WorkbenchPage.java:3469)
	at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3487)
	at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:76)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
	at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1072)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4133)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1495)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1491)
	at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:497)
	at org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1060)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5585)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
	at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5495)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:221)
	at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2102)
	at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2299)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5557)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:5002)
	at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5151)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3616)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1029)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:923)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)


 Comments   
Comment by Andrew Eisenberg [ 05/Oct/12 ]

Originally reported in GRECLIPSE-1514, but this issues narrows down the problem.

Comment by Andrew Eisenberg [ 27/Nov/12 ]

Still a problem on generics branch.

Comment by Andy Clement [ 14/Dec/12 ]

This code behaves strangely on the command line. Compiling with 2.0.4 just prints 'null' (and produces no class files), compiling with 2.0.5 it does print what we expect (no method keySet). So I suspect our greclipse behaviour would change with a 2.0.5 update.

Comment by Andrew Eisenberg [ 24/Apr/13 ]

Now working for me with the 2.1.2 compiler.





[GRECLIPSE-1514] CompileStatic stack overflow issue Created: 05/Oct/12  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic, stability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive groovy-lib.zip    
Issue Links:
Related
relates to GRECLIPSE-1515 CompileStatic NPE when doing the bitw... Resolved
Number of attachments : 1

 Description   

In this project, the StaticTools.groovy script causes a stack overflow somewhere due to CompileStatic.

Additionally, the Props.groovy class has a problem on line 145 that is causing an NPE in the compiler. A bitwise negation expression is being applied to a regex improperly. It should be a String.



 Comments   
Comment by Andrew Eisenberg [ 05/Oct/12 ]

This code causes the same stack overflow:

@CompileStatic
class C {
  def xxx(List list) {
    list.unique().each { }
  }
}
Comment by Andrew Eisenberg [ 19/Nov/12 ]

Still a problem in the generics branch.

Comment by Andy Clement [ 14/Dec/12 ]

This is a groovy bug https://jira.codehaus.org/browse/GROOVY-5846
Fails on 2.0.4 and 2.0.5

Comment by Andrew Eisenberg [ 24/Apr/13 ]

Working now on groovy 2.1.2 compiler.





[GRECLIPSE-1513] Hover over constructor name and exception Created: 05/Oct/12  Updated: 04/Jan/13  Resolved: 04/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This code:

class C {
	C() {}
}

Hover over the C of the constructor and you get this exception:

java.lang.IllegalArgumentException
	at org.eclipse.jdt.core.Signature.getTypeParameters(Signature.java:2373)
	at org.eclipse.jdt.core.Signature.getTypeParameters(Signature.java:2430)
	at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLabelComposer.appendTypeLabel(JavaElementLabelComposer.java:1010)
	at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLabelComposer.appendElementLabel(JavaElementLabelComposer.java:285)
	at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLinks.getElementLabel(JavaElementLinks.java:559)
	at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLinks.getElementLabel(JavaElementLinks.java:541)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getInfoText(JavadocHover.java:679)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo(JavadocHover.java:612)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.internalGetHoverInfo(JavadocHover.java:565)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo2(JavadocHover.java:557)
	at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:163)
	at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:129)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo2(JavaEditorTextHoverProxy.java:85)
	at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:166)


 Comments   
Comment by Andrew Eisenberg [ 04/Jan/13 ]

Issue is fixed. See commit 405516a on github.





[GRECLIPSE-1512] Operator overloading for 'div' not recognized Created: 05/Oct/12  Updated: 05/Oct/12  Resolved: 05/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Trying this:

enum Duration {
	hour
}

@TupleConstructor
class Distance {
	double amount
	Unit unit
	
	Speed div(Duration dur) {
		new Speed(amount, unit)
	}
	
	String toString() { "$amount$unit" }
}

@TupleConstructor
class Speed {
	double amount
	Unit unit
	
	String toString() { "$amount $unit/h" }
}

def speed   = distance/duration

Hover over speed and you see String. Should be Speed.



 Comments   
Comment by Andrew Eisenberg [ 05/Oct/12 ]

Turns out I was trying to overload the divide method in {TypeInferencingVisitorWithRequestor}}, but I should have been overloading div.

And the tests were testing the wrong thing. Fixed now.





[GRECLIPSE-1511] Invalid static compile error Created: 05/Oct/12  Updated: 27/Nov/12  Resolved: 27/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Possibly a regression after fixing GRECLIPSE-1504.

This code has a static compilation compile error on the last line of the method:

@groovy.transform.CompileStatic
def meth() {
	List<String> second = []
	List<String> artefactResources2
	second.addAll(artefactResources2)
}


 Comments   
Comment by Andrew Eisenberg [ 19/Nov/12 ]

Fixed in the generics branch on github.

Comment by Andrew Eisenberg [ 27/Nov/12 ]

Fixed with regression test. Thanks Andy.





[GRECLIPSE-1506] Compile static and type checked problem with AST transform Created: 01/Oct/12  Updated: 18/Jan/15  Resolved: 23/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic, stability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive loggerproblemcutdown.tar.gz    
Number of attachments : 1

 Description   

The following code compiles on the command line, but not with greclipse using the 2.0.4 patched compiler:

@Slf4j
@TypeChecked
public class LoggerTest
{
	public static void main(String... args)
	{
		println "println"
		LoggerTest.log.info("Logged");
		log.info("foo")
	}
}

Same behavior with @CompileStatic. Two problems:

Description	Resource	Path	Location	Type
Groovy:[Static type checking] - Cannot find matching method org.slf4j.Logger#info(java.lang.String). Please check if the declared type is right and if the method exists.	DynamicQuery.groovy	/Sample_Java/src/com/any	line 24	Java Problem
Groovy:[Static type checking] - Cannot find matching method org.slf4j.Logger#info(java.lang.String). Please check if the declared type is right and if the method exists.	DynamicQuery.groovy	/Sample_Java/src/com/any	line 25	Java Problem

Looks like the results of the AST transform are not being used to populate the type checker.



 Comments   
Comment by Andy Clement [ 02/Oct/12 ]

what jar from groovy do i put on my classpath to compile this program on the command line?

Comment by Andrew Eisenberg [ 02/Oct/12 ]

It's not included with groovy AFAICT. I used one from my my m2 repo.

This should work. ~/.m2/repository/org/slf4j/slf4j-api/1.6.4/slf4j-api-1.6.4.jar

Comment by Jim Hazen [ 12/Oct/12 ]

mvn clean; mvn compile
to reproduce

Comment by Andy Clement [ 17/Dec/12 ]

I believe this is a classloader issue. The 'fake' classnode created when the real classloader can't find the slf4j types is no use to the type checking code (it contains no fields/methods etc). If the transform classloader had been used, the right slf4j type would have been found.

Comment by Andrew Eisenberg [ 24/Apr/13 ]

Still a problem with Groovy 2.1.2 compiler.

Comment by Andrew Eisenberg [ 07/May/13 ]

Wonder if this is related to GROOVY-5736.

Comment by Andrew Eisenberg [ 23/May/13 ]

Currently, this is manifesting as a reconcile error only. The compile is clean. I will see why, and strongly suspect that an incorrect classloader is being used.

Comment by Andrew Eisenberg [ 23/May/13 ]

Added org.eclipse.jdt.core.compiler.groovy.groovyTransformsToRunOnReconcile=groovy.util.logging.Slf4j to .settings/org.eclipse.jdt.core.prefs and now everything works. Resolving this issue.

Comment by Hendy Irawan [ 18/Jan/15 ]

wrong ticket, should be GROOVY-5902





[GRECLIPSE-1505] @TypeChecked compile error in collect Created: 01/Oct/12  Updated: 02/Oct/12  Resolved: 02/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File patch1505.txt    
Number of attachments : 1

 Description   

This code has a compile error in greclipse with the 2.0.4 compiler:

@TypeChecked
class DynamicQuery {
    private foo(Map sumpin){
		Map foo
		foo.collect{ Map.Entry it ->it.key}
    }
}

This error does not appear on command line.



 Comments   
Comment by Andrew Eisenberg [ 01/Oct/12 ]

Here is text of error:

Groovy:[Static type checking] - Cannot find matching method java.util.Map#collect(groovy.lang.Closure <K>). Please check if the declared type is right and if the method exists.
Comment by Andy Clement [ 02/Oct/12 ]

This patch for JDTClassNode will make the code work. However, once applied it breaks some of the inferencing tests. The patch is intended to ensure JDTClassNodes more closely resemble ClassNodes. Properties are only added to ClassNodes when fields are parsed by the parser (or, less frequently, when a particular ast transform is used). Currently our JDTClassNode always adds properties even for types that groovy cannot have parsed. In the case here it is Map.Entry where key/value are added as properties, where strictly speaking, according to groovyc they would not be set as properties on a classnode.

Comment by Andy Clement [ 02/Oct/12 ]

test is in GroovySimpleTests (pushed) - commented out for now.

Comment by Andrew Eisenberg [ 02/Oct/12 ]

fixed now





[GRECLIPSE-1504] groovy-eclipse-compiler plugin problems with @Log4j Created: 01/Oct/12  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Following up with GRECLIPSE-1503, the groovy-eclipse-compiler plugin also does not work with @Log4j. The solution will be separate. I need to add a dependency on log4j from the compiler plugin.



 Comments   
Comment by george coller [ 01/Oct/12 ]

See my comment from GRECLIPSE-1503 where I explain what I think happened and the workaround.

Comment by Jim Hazen [ 01/Oct/12 ]

Andrew, I suspect this might be a problem with every AST that requires external dependencies (log4j, slf4j, something else). Instead of trying to add explicit dependencies on log4j, slf4j, etc to the compiler plugin or batch (hard to manage and may be impossible to scale with user supplied ASTs). Instead allow the compiler to use the main project's dependency classpath, along with plugin dependency path overrides?

Dunno enough about maven plugins to know if what I suggest is possible, just thinking out loud. Would hate to get this fixed for log4j and still leave slf4j broken.

Comment by Andrew Eisenberg [ 01/Oct/12 ]

A simple workaround, as I described on the mailing list is this to add the following dependency to the maven-compiler-plugin (right next to the dependency for groovy-eclispe-compiler):

                                        <dependency>
                                                <groupId>log4j</groupId>
                                                <artifactId>log4j</artifactId>
                                                <version>1.2.16</version>
                                                <scope>runtime</scope>
                                        </dependency>

This goes in project -> build -> plugins -> plugin
(maven-compiler-plugin) -> dependencies

Comment by Andrew Eisenberg [ 01/Oct/12 ]

I rebuilt the groovy-eclipse-batch artifact with version 2.0.4-03. It is now on maven central. It includes the fix from GRECLIPSE-1503. I tested this and things appear to be working. The dependency I describe in the previous comment is no longer necessary. You just need to add a dependency to 2.0.4-03.

Comment by Andrew Eisenberg [ 01/Oct/12 ]

Marking this issue as resolved, but please comment or re-open if there is something else.





[GRECLIPSE-1503] The @Log4j ast transform crashes the compiler Created: 01/Oct/12  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to GROOVY-5736 Log4j, Commons, Slf4j ast transforms ... Open
Number of attachments : 0

 Description   

Due to a missing dependency in the compiler, the following code crashes groovy-eclipse:

@Log4j
class A {
	
}

The following stack trace is generated by the compiler:

General error during semantic analysis: null

groovy.lang.GroovyRuntimeException: null
at org.codehaus.groovy.transform.LogASTTransformation$AbstractLoggingStrategy.classNode(LogASTTransformation.java:235)
at groovy.util.logging.Log4j$Log4jLoggingStrategy.addLoggerFieldToClass(Log4j.java:70)
at org.codehaus.groovy.transform.LogASTTransformation$1.visitClass(LogASTTransformation.java:91)
at org.codehaus.groovy.transform.LogASTTransformation.visit(LogASTTransformation.java:136)
at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1191)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:601)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:578)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1994)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:827)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:648)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:758)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:746)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.codehaus.groovy.transform.LogASTTransformation$AbstractLoggingStrategy.classNode(LogASTTransformation.java:233)
... 14 more



 Comments   
Comment by george coller [ 01/Oct/12 ]

Looks like on September 30 they released two bad groovy-eclipse-batch versions: 2.0.4-01 and 2.0.4-02 that have this log4j classloader issue.

Since groovy-eclipse-compiler has pom.xml settings to go out and grab the latest groovy-eclipse-batch release (which is a dangerous way to do dependency management) it is breaking the build.

The workaround until they fix this is to edit your local copy ~/.m2/repository/org/codehous/groovy/groovy-eclipse-compiler/2.7.0-01/pom.xml from

<dependency>
  <groupId>org.codehaus.groovy</groupId>
  <artifactId>groovy-eclipse-batch</artifactId>
  <version>[1.7.10-02,1.7.10-99],[1.8.2-01,9.9.9)</version> <!-- Allowing new, untested versions in is dangerous -->
</dependency> 

To

<dependency>
  <groupId>org.codehaus.groovy</groupId>
  <artifactId>groovy-eclipse-batch</artifactId>
  <version>2.0.0-01</version> <!-- Last good version -->
</dependency> 
Comment by Jim Hazen [ 01/Oct/12 ]

It might be better to hack your project's pom, rather than crack open the groovy-eclipse-compiler. Below is another work around. From my project's pom:

<build>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.5.1</version>
                <configuration>
                    <compilerId>groovy-eclipse-compiler</compilerId>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-compiler</artifactId>
                        <version>2.7.0-01</version>
                    </dependency>
                    <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-batch</artifactId>
                        <version>2.0.0-01</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>
Comment by Andrew Eisenberg [ 01/Oct/12 ]

Note that this bug is not about maven support, but about running this code inside of Eclipse. For the maven support bug, look at GRECLIPSE-1504. See my workaround there.

Comment by Andrew Eisenberg [ 01/Oct/12 ]

After looking deeper, there is a change in Groovy from 2.0.1 (see GROOVY-5574 and GROOVY-5557) where the compiler now loads the logging class using Class.forName. This will not work in groovy-eclipse since the compiler classloader and the project classloader are separated. This is not typically the case for pure groovy compilation.

So, this is a compiler integration bug that we picked up when we moved to the 2.0.4 compiler.

Comment by Andrew Eisenberg [ 01/Oct/12 ]

Found a fix for us and raised GROOVY-5736 to propose the fix in the compiler. This fix will not be available until 2.0.5 and so we will probably provide a patch for this fix ourselves.

Comment by Andrew Eisenberg [ 01/Oct/12 ]

Added regression test for the fix described in GROOVY-5736. Pushed. This fix will be available in next snapshot build of the eclipse plugin. Now to rebuild the groovy-eclipse-batch maven artifact.

Comment by Andrew Eisenberg [ 01/Oct/12 ]

Fixed.





[GRECLIPSE-1502] DSLD support for groovy command chain calls Created: 25/Sep/12  Updated: 26/Sep/12  Resolved: 26/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, DSL Support
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using command chains in a script, inferencing is working, but content assist is not correct. This bug deals with applying a command chain proposal. It should be applied without parens.



 Comments   
Comment by Andrew Eisenberg [ 26/Sep/12 ]

Fixed. There is a new option for method contribution in DSLDs. You can now add noParens=true to a contribution and the proposal will be applied without parens using command chain style.





[GRECLIPSE-1501] Support Groovy command chain method invocation for content assist Created: 25/Sep/12  Updated: 26/Sep/12  Resolved: 26/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using command chains in a script, inferencing is working, but content assist is not correct. Eg-

move right b|y 10.meters

do content assist at the | and you would expect to see by. However, the target of invocation is interpreted as being a new statement the results are incorrect.



 Comments   
Comment by Andrew Eisenberg [ 26/Sep/12 ]

Done. content assist is now working as expected for command chain expressions. The solution is tied up with GRECLIPSE-1502, where you can specify command chain style method contributions in your dsld.





[GRECLIPSE-1500] NPE when content assist invoked in same file as an explicit script sub-class Created: 24/Sep/12  Updated: 24/Sep/12  Resolved: 24/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider this:

class FooScript extends Script { }
|

Content assist at the | gives this exception:

java.lang.NullPointerException
	at org.codehaus.groovy.eclipse.codeassist.requestor.CompletionNodeFinder.internalVisitConstructorOrMethod(CompletionNodeFinder.java:320)
	at org.codehaus.groovy.eclipse.codeassist.requestor.CompletionNodeFinder.visitClass(CompletionNodeFinder.java:245)
	at org.codehaus.groovy.eclipse.codeassist.requestor.CompletionNodeFinder.internalVisitModuleNode(CompletionNodeFinder.java:143)
	at org.codehaus.groovy.eclipse.codeassist.requestor.CompletionNodeFinder.findContentAssistContext(CompletionNodeFinder.java:124)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.createContentAssistContext(GroovyCompletionProposalComputer.java:222)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.computeCompletionProposals(GroovyCompletionProposalComputer.java:147)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:333)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:340)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:328)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:284)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
...

Looks like the completion visitor is looking for a run method and finding the one in the super class. The NPE happens because Script.run has no body.



 Comments   
Comment by Andrew Eisenberg [ 24/Sep/12 ]

Simple fix is to ensure that when checking for run methods, the declaring type is the same as the current type.

Fix is committed and pushed.





[GRECLIPSE-1499] Need an easy way to set the 'Groovy compiler level' for a group of projects Created: 21/Sep/12  Updated: 04/Jan/13  Resolved: 04/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Scenario:

  • open/import a bunch of projects that don't have a preferred compiler level set.
  • compiler level gets set automatically and silently to the current compiler

This is mighty annoying if the setting happens to be wrong.
Because my next step is

  • switch the 'workspace compiler level' to what I really want to use
    => now all of my projects have errors that they have the wrong level
    => I have to fix each project one by one.

Event though there is a 'quick fix' option on the problem marker in the problems view, if I have 30+ projects in my workspace, it is still mighty annoying to invoke this quickfix 30+ times, each time selecting the same option to 'set compiler level to workspace level'.

I should be able to just select a bunch of projects and 'set compiler level to workspace level' on all of them at once, from the project's context menu.

I just ran into this by doing the following:

  • grails-core projects checked out in my workspace on 'master branch'
    => uses 2.0 compiler has 2.0 compiler
  • git checkout v2.1.1
    => this tagged version has no compiler level prefs files in the git repo.
    AND it needs 1.8
    As soon as I checked out the tagged version, Greclipse immiately marked all these projects incorrectly as requiring Groovy 2.0.


 Comments   
Comment by Andrew Eisenberg [ 21/Sep/12 ]

I can see how this can be annoying. What I need is a dialog somewhere that lists all groovy projects with checkboxes next to them. And it allows you to set compiler levels for all checked projects.

I will work on this for 2.7.2.

Comment by Andrew Eisenberg [ 21/Sep/12 ]

Some work on this. Now it is actually possible to select multiple problems at once and choose to resolve them all. However, separate dialogs for each changed project appears. It would be better if only one dialog appeared.

Comment by Andrew Eisenberg [ 04/Jan/13 ]

Fixed. There is now a command in Project -> Groovy -> Fix Compiler levels. There is also appropriate UI.





[GRECLIPSE-1498] Move to JDT 3.8.1 Created: 21/Sep/12  Updated: 21/Sep/12  Resolved: 21/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Improvement Priority: Blocker
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We will release Groovy-Eclipse 2.7.1 after we have updated the JDT patch to 3.8.1.



 Comments   
Comment by Andy Clement [ 21/Sep/12 ]

Complete. The jdt build for eclipse 3.8.1 is actually a 3.8.2 build (eclipse 3.8.0 had a 3.8.1 jdt in it).





[GRECLIPSE-1497] Move to Groovy 2.0.4 Created: 21/Sep/12  Updated: 21/Sep/12  Resolved: 21/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Improvement Priority: Blocker
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We will release Groovy-Eclipse 2.7.1 after we have updated to Groovy 2.0.4.



 Comments   
Comment by Andy Clement [ 21/Sep/12 ]

All done. Nothing to serious, which surprised me. Things of note: they have new message types that actually take start and end positions, and are using them in a few places. They have the new plugin resolver mechanism but we are not yet exploiting it, we are still just subclassing the existing resolver.





[GRECLIPSE-1496] Thread dead lock while modifying Groovy files Created: 20/Sep/12  Updated: 20/Sep/12  Resolved: 20/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.7.0.Release
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Gian Mario Contessa Assignee: Unassigned
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Hi, I was just modifying my groovy files and at saving time it locked.

Here is the thread dump with the lock:

---------------
Name: org.eclipse.jdt.internal.ui.text.JavaReconciler
State: BLOCKED on java.lang.Object@1ec9593d owned by: main
Total blocked: 2  Total waited: 81

Stack trace: 
org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$CompilationUnitAnnotationModel.internalBeginReporting(CompilationUnitDocumentProvider.java:583)
org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$CompilationUnitAnnotationModel.beginReportingSequence(CompilationUnitDocumentProvider.java:568)
org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:103)
org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
------------------
Name: main
State: BLOCKED on org.codehaus.jdt.groovy.model.ModuleNodeMapper@68ed6506 owned by: Recommenders-Timeout-Manager
Total blocked: 5,289  Total waited: 168

Stack trace: 
org.codehaus.jdt.groovy.model.ModuleNodeMapper.maybeCacheModuleNode(ModuleNodeMapper.java:105)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.maybeCacheModuleNode(GroovyCompilationUnit.java:399)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:348)
org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1100)
org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:60)
org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:423)
org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1231)
org.eclipse.jdt.internal.corext.util.JavaModelUtil.reconcile(JavaModelUtil.java:594)
org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:283)
org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:199)
org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:183)
org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$5$1.getSelection(JavaEditor.java:2247)
org.eclipse.ui.internal.WorkbenchPage.updateShowInSources(WorkbenchPage.java:362)
org.eclipse.ui.internal.e4.compatibility.SelectionService$1.selectionChanged(SelectionService.java:76)
org.eclipse.e4.ui.internal.workbench.SelectionAggregator$2.run(SelectionAggregator.java:111)
org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
org.eclipse.e4.ui.internal.workbench.SelectionAggregator.notifyListeners(SelectionAggregator.java:109)
org.eclipse.e4.ui.internal.workbench.SelectionAggregator.access$4(SelectionAggregator.java:106)
org.eclipse.e4.ui.internal.workbench.SelectionAggregator$4$1.run(SelectionAggregator.java:163)
org.eclipse.e4.core.contexts.RunAndTrack.runExternalCode(RunAndTrack.java:53)
   - locked org.eclipse.e4.ui.internal.workbench.SelectionAggregator$4@275cdcd
org.eclipse.e4.ui.internal.workbench.SelectionAggregator$4.changed(SelectionAggregator.java:161)
org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:109)
org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:308)
org.eclipse.e4.core.internal.contexts.EclipseContext.set(EclipseContext.java:322)
org.eclipse.e4.ui.internal.workbench.SelectionServiceImpl.setSelection(SelectionServiceImpl.java:30)
org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.selectionChanged(CompatibilityPart.java:420)
org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:164)
org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:162)
org.eclipse.jface.text.TextViewer.fireSelectionChanged(TextViewer.java:2738)
org.eclipse.jface.text.TextViewer.selectionChanged(TextViewer.java:2717)
org.eclipse.jface.text.TextViewer.setSelectedRange(TextViewer.java:2402)
org.eclipse.jface.text.TextViewer$ViewerState.restore(TextViewer.java:1237)
org.eclipse.jface.text.TextViewer.enabledRedrawing(TextViewer.java:5096)
org.eclipse.jface.text.TextViewer.enabledRedrawing(TextViewer.java:5071)
org.eclipse.jface.text.TextViewer.setRedraw(TextViewer.java:5156)
org.eclipse.jface.text.TextViewer.setRedraw(TextViewer.java:5130)
org.eclipse.jface.text.TextViewer$RewriteTarget.setRedraw(TextViewer.java:1067)
org.eclipse.jface.text.TextViewer$DocumentRewriteSessionListener.documentRewriteSessionChanged(TextViewer.java:1478)
org.eclipse.jface.text.AbstractDocument.fireRewriteSessionChanged(AbstractDocument.java:1559)
org.eclipse.jface.text.AbstractDocument.stopRewriteSession(AbstractDocument.java:1648)
org.eclipse.core.internal.filebuffers.SynchronizableDocument.stopRewriteSession(SynchronizableDocument.java:113)
   - locked java.lang.Object@1ec9593d
org.eclipse.jface.text.TextViewer.shift(TextViewer.java:4408)
org.eclipse.jface.text.TextViewer.doOperation(TextViewer.java:4013)
org.eclipse.jface.text.source.SourceViewer.doOperation(SourceViewer.java:1018)
org.eclipse.jface.text.source.projection.ProjectionViewer.doOperation(ProjectionViewer.java:1424)
org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.doOperation(JavaSourceViewer.java:191)
org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:200)
org.eclipse.ui.texteditor.ShiftAction$1.run(ShiftAction.java:85)
org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
org.eclipse.ui.texteditor.ShiftAction.run(ShiftAction.java:83)
org.eclipse.ui.texteditor.AbstractTextEditor$ActivationCodeTrigger.verifyKey(AbstractTextEditor.java:783)
org.eclipse.jface.text.TextViewer$VerifyKeyListenersManager.verifyKey(TextViewer.java:491)
org.eclipse.swt.custom.StyledTextListener.handleEvent(StyledTextListener.java:65)
org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:774)
org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5932)
org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5629)
org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1521)
org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640)
org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345)
org.eclipse.swt.widgets.Control.windowProc(Control.java:4528)
org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
org.eclipse.swt.widgets.Display.windowProc(Display.java:4976)
org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546)
org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:601)
org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
org.eclipse.equinox.launcher.Main.run(Main.java:1438)
org.eclipse.equinox.launcher.Main.main(Main.java:1414)
--------------------
Name: Recommenders-Timeout-Manager
State: BLOCKED on java.lang.Object@1ec9593d owned by: main
Total blocked: 438  Total waited: 8,963

Stack trace: 
org.eclipse.core.internal.filebuffers.SynchronizableDocument.get(SynchronizableDocument.java:126)
org.eclipse.jdt.internal.ui.javaeditor.DocumentAdapter.getContents(DocumentAdapter.java:385)
org.eclipse.jdt.internal.ui.javaeditor.DocumentAdapter.getCharacters(DocumentAdapter.java:377)
org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:671)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit$CompilationUnitClone.getContents(GroovyCompilationUnit.java:461)
org.codehaus.jdt.groovy.integration.internal.MultiplexingCommentRecorderParser.dietParse(MultiplexingCommentRecorderParser.java:55)
org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:775)
org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:949)
org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1025)
org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody0(CompilationUnitProblemFinder.java:209)
org.eclipse.jdt.internal.core.CompilationUnitProblemFinder$AjcClosure1.run(CompilationUnitProblemFinder.java:1)
scala.tools.eclipse.contribution.weaving.jdt.core.CompilationUnitProblemFinderAspect.ajc$around$scala_tools_eclipse_contribution_weaving_jdt_core_CompilationUnitProblemFinderAspect$1$3edd546aproceed(CompilationUnitProblemFinderAspect.aj:1)
scala.tools.eclipse.contribution.weaving.jdt.core.CompilationUnitProblemFinderAspect.ajc$around$scala_tools_eclipse_contribution_weaving_jdt_core_CompilationUnitProblemFinderAspect$1$3edd546a(CompilationUnitProblemFinderAspect.aj:49)
org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:172)
org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:275)
org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:80)
org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:98)
org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:423)
org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1219)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.getModuleInfo(GroovyCompilationUnit.java:125)
   - locked org.codehaus.jdt.groovy.model.ModuleNodeMapper@68ed6506
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.getModuleNode(GroovyCompilationUnit.java:102)
org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectHelper.select(CodeSelectHelper.java:39)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:503)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:495)
org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:490)
org.eclipse.recommenders.internal.rcp.providers.JavaSelectionUtils.resolveJavaElementFromTypeRootInEditor(JavaSelectionUtils.java:147)
org.eclipse.recommenders.internal.rcp.providers.JavaSelectionUtils.resolveJavaElementFromEditor(JavaSelectionUtils.java:129)
org.eclipse.recommenders.internal.rcp.providers.JavaSelectionUtils.resolveJavaElementFromEditor(JavaSelectionUtils.java:112)
org.eclipse.recommenders.internal.rcp.providers.JavaSelectionProvider.handleSelectionInEditor(JavaSelectionProvider.java:108)
org.eclipse.recommenders.internal.rcp.providers.JavaSelectionProvider.access$1(JavaSelectionProvider.java:105)
org.eclipse.recommenders.internal.rcp.providers.JavaSelectionProvider$1.run(JavaSelectionProvider.java:82)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
java.util.concurrent.FutureTask.run(FutureTask.java:166)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
java.lang.Thread.run(Thread.java:722)


 Comments   
Comment by Andrew Eisenberg [ 20/Sep/12 ]

Please update to the latest snapshot. GRECLIPSE-1463 addressed a deadlock very similar to this.

Use this update site:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e4.2/
or this one for Eclipse 3.7:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

Comment by Gian Mario Contessa [ 20/Sep/12 ]

Ok, I'll try it thanks!
In case I still have problems I'll reopen the bug





[GRECLIPSE-1494] Unable to load class GroovyEditor Created: 17/Sep/12  Updated: 28/Sep/12  Resolved: 28/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Serge Grey Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04, Eclipse juno 20120614-1722


Attachments: PNG File exception.png    
Number of attachments : 1

 Description   

When I try to view 'groovy-file' exception appears

org.eclipse.core.runtime.CoreException: Plug-in org.codehaus.groovy.eclipse.ui was unable to load class org.codehaus.groovy.eclipse.editor.GroovyEditor.
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.throwException(RegistryStrategyOSGI.java:194)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:176)
at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55)
at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:273)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:269)
at org.eclipse.ui.internal.registry.EditorDescriptor.createEditor(EditorDescriptor.java:235)
at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:283)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPart(CompatibilityPart.java:249)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor.createPart(CompatibilityEditor.java:60)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:286)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:857)
at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:837)
at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:111)
at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:318)
at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:240)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:161)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:102)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53)
at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:141)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:889)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:623)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:725)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:696)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:690)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:675)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl$1.handleEvent(PartServiceImpl.java:90)
at org.eclipse.e4.ui.services.internal.events.UIEventHandler$1.run(UIEventHandler.java:41)
at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180)
at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150)
at org.eclipse.swt.widgets.Display.syncExec(Display.java:4291)
at org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:187)
at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:38)
at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135)
at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78)
at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39)
at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:81)
at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:57)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElement(ElementContainerImpl.java:171)
at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.showElementInWindow(ModelServiceImpl.java:418)
at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.bringToTop(ModelServiceImpl.java:385)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.delegateBringToTop(PartServiceImpl.java:578)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.bringToTop(PartServiceImpl.java:314)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:962)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:3071)
at org.eclipse.ui.internal.WorkbenchPage.access$21(WorkbenchPage.java:2996)
at org.eclipse.ui.internal.WorkbenchPage$8.run(WorkbenchPage.java:2978)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2974)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2933)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2924)
at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:373)
at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:179)
at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:249)
at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:228)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:275)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251)
at org.eclipse.jdt.internal.ui.packageview.PackageExplorerActionGroup.handleOpen(PackageExplorerActionGroup.java:376)
at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$4.open(PackageExplorerPart.java:538)
at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:48)
at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:866)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:864)
at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1152)
at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1256)
at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:275)
at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:269)
at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:309)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1276)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3554)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3179)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
Caused by: org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: An error occurred while automatically activating bundle org.codehaus.groovy.eclipse.ui (455).
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:122)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:464)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.codehaus.groovy.eclipse.ui.decorators.GroovyPluginImages.<clinit>(GroovyPluginImages.java:38)
at org.codehaus.groovy.eclipse.ui.decorators.GroovyImageDecorator.getJavaElementImageDescriptor(GroovyImageDecorator.java:131)
at org.codehaus.groovy.eclipse.ui.decorators.GroovyImageDecorator.decorateImage(GroovyImageDecorator.java:86)
at org.eclipse.ui.internal.decorators.FullDecoratorDefinition.decorateImage(FullDecoratorDefinition.java:114)
at org.eclipse.ui.internal.decorators.FullImageDecoratorRunnable.run(FullImageDecoratorRunnable.java:28)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.decorators.DecoratorManager.safeDecorateImage(DecoratorManager.java:642)
at org.eclipse.ui.internal.decorators.DecoratorManager.decorateImage(DecoratorManager.java:590)
at org.eclipse.ui.internal.decorators.DecoratorManager$ManagedWorkbenchLabelDecorator.decorateImage(DecoratorManager.java:149)
at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider.getImage(DecoratingStyledCellLabelProvider.java:173)
at org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider.update(DelegatingStyledCellLabelProvider.java:118)
at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider.update(DecoratingStyledCellLabelProvider.java:134)
at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:152)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:953)
at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:113)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1033)
at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:485)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2167)
at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:848)
at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:823)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:797)
at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:644)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:768)
at org.eclipse.jface.viewers.AbstractTreeViewer.setExpandedState(AbstractTreeViewer.java:2500)
at org.eclipse.jdt.internal.ui.packageview.PackageExplorerActionGroup.handleDoubleClick(PackageExplorerActionGroup.java:352)
at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$3.doubleClick(PackageExplorerPart.java:515)
at org.eclipse.jface.viewers.StructuredViewer$1.run(StructuredViewer.java:845)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.StructuredViewer.fireDoubleClick(StructuredViewer.java:843)
at org.eclipse.jface.viewers.AbstractTreeViewer.handleDoubleSelect(AbstractTreeViewer.java:1477)
at org.eclipse.jface.viewers.StructuredViewer$4.widgetDefaultSelected(StructuredViewer.java:1246)
at org.eclipse.jface.util.OpenStrategy.fireDefaultSelectionEvent(OpenStrategy.java:249)
at org.eclipse.jface.util.OpenStrategy.access$0(OpenStrategy.java:246)
at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:307)
... 25 more
Caused by: org.osgi.framework.BundleException: Exception in org.codehaus.groovy.eclipse.GroovyPlugin.start() of bundle org.codehaus.groovy.eclipse.ui.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440)
at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
... 76 more
Caused by: java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/debug/ui/JDIDebugUIPlugin
at org.codehaus.groovy.eclipse.GroovyPlugin.start(GroovyPlugin.java:187)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
... 82 more
Caused by: org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.jdt.debug.ui (201).
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:122)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 86 more
Caused by: org.osgi.framework.BundleException: The activator org.eclipse.jdt.internal.debug.ui.JDIDebugUIPlugin for bundle org.eclipse.jdt.debug.ui is invalid
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:172)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:679)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440)
at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
... 95 more
Caused by: java.lang.NoClassDefFoundError: org/eclipse/jdt/debug/core/IJavaHotCodeReplaceListener
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404)
at java.lang.Class.getConstructor0(Class.java:2714)
at java.lang.Class.newInstance0(Class.java:343)
at java.lang.Class.newInstance(Class.java:325)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:167)
... 101 more
Caused by: org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.jdt.debug (200).
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:122)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 107 more
Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.jdt.internal.debug.core.JDIDebugPlugin.start() of bundle org.eclipse.jdt.debug.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440)
at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
... 116 more
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.ibm.icu.text.SimpleDateFormat
at org.eclipse.jdt.internal.debug.core.JDIDebugOptions.<clinit>(JDIDebugOptions.java:58)
at org.eclipse.jdt.internal.debug.core.JDIDebugPlugin.start(JDIDebugPlugin.java:274)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
... 122 more



 Comments   
Comment by Andrew Eisenberg [ 17/Sep/12 ]

The root cause of the exception is Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.ibm.icu.text.SimpleDateFormat, which implies that there is something wrong with the com.ibm.icu bundle. I am not sure why this would happen, but it does not seem to be directly related to Groovy-Eclipse.

We could go around and around trying to figure out exactly what is happening, but I think it would save time if you just reinstalled Eclipse and Groovy-Eclipse from scratch. Make sure to download a package from eclipse.org, not the one bundled from Ubuntu. Also, make sure to install in a writable directory.

Comment by Serge Grey [ 24/Sep/12 ]

I reinstalled the eclipse and groovy, the result remaining the same. In the windows everything works fine.

Comment by Andrew Eisenberg [ 24/Sep/12 ]

How did you install Eclipse? Did you install from Eclipse.org? A little googling shows that this is probably an Ubuntu distribution problem on openJDK. See here:

http://comments.gmane.org/gmane.comp.java.openjdk.general/3006

Comment by Serge Grey [ 28/Sep/12 ]

Bug disappeared after today's update Ubuntu.

Comment by Andrew Eisenberg [ 28/Sep/12 ]

Thanks for the feedback. Closing this issue.





[GRECLIPSE-1493] Groovy tests in src/test/groovy ignored Created: 11/Sep/12  Updated: 12/Sep/12  Resolved: 12/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.6.0.Release, 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Joshua Davis Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive TestProject.zip    
Number of attachments : 1

 Description   

My groovy tests are ignored when using the groovy-eclipse-compiler and there are no src/main/java or src/test/java folders

I have viewed both
http://jira.codehaus.org/browse/GRECLIPSE-1221
and
http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven

Per the jira and the documentation I should just have to specify the plugin

<plugin>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy-eclipse-compiler</artifactId>
    <version>2.7.0-01</version>
    <extensions>true</extensions>
  </plugin>

along with the changes to the maven-compiler-plugin

But it doesn't seem to be working for me.

I have attached a sample project.
When I run mvn clean test it says there are no tests when in fact there is 1.

If I move the groovy files into src/main/java and src/test/java it works fine.



 Comments   
Comment by Andrew Eisenberg [ 11/Sep/12 ]

I tried running your project and this is what I get:

$ mvn test
[INFO] Scanning for projects...
<SNIP/>
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running test.project.MyGroovyTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.523 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.046s
[INFO] Finished at: Tue Sep 11 16:16:46 PDT 2012
[INFO] Final Memory: 8M/1014M
[INFO] ------------------------------------------------------------------------

It looks like the tests are running for me. Several things to look at:

  1. What version of maven are you using? I am on 3.0.3.
  2. Perhaps your local repo is corrupt and you are using invalid versions of groovy-eclipse-compiler. Try clearing that part of your local repo and trying again.

Run something like this:

rm -rf ~/.m2/repository/org/codehaus/groovy/groovy-eclipse-compiler ~/.m2/repository/org/codehaus/groovy/groovy-eclipse-batch
mvn test
Comment by Joshua Davis [ 12/Sep/12 ]

I am using maven 2.2.1, and your right apparently my local was corrupt. I cleaned my local and then it worked fine. I should of tried cleaning it before I logged the issue. It never occurred to me though that it would be corrupt.

Thanks for your help.

Comment by Andrew Eisenberg [ 12/Sep/12 ]

No problem. It took me a long time to realize that the solution to most maven problems is to clear the local cache.





[GRECLIPSE-1488] When a List initializer has more than 28 characters between the brackets, the formatter adds a bunch of unnecessary new lines. Created: 05/Sep/12  Updated: 28/Sep/12  Resolved: 28/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Jon Williams Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Eclipse Indigo, GRECLIPSE Version: 2.7.0.xx-20120703-1400-e37-RELEASE


Issue Links:
Duplicate
duplicates GRECLIPSE-1355 Formatter splitting single list eleme... Resolved
Number of attachments : 0

 Description   

When a List initializer has more than 28 characters between the brackets, the formatter adds a bunch of unnecessary new lines and extra indentation.

Example:

List<String> strings28 = ['1x', '2xx', '3xxx', '4xxxx']; // 28 chars between []
List<String> strings29 = ['1x', '2xx', '3xxx', '4xxxx' ]; // 29 chars between []

After formatting becomes:

List<String> strings28 = ['1x', '2xx', '3xxx', '4xxxx']; // 28 chars between []
List<String> strings29 = [
'1x',
'2xx',
'3xxx',
'4xxxx'
]; // 29 chars between []

Issue occurs with all built-in Formatter profiles (and one custom profile)



 Comments   
Comment by Jon Williams [ 05/Sep/12 ]

likely same root cause as issue GRECLIPSE-1355

Comment by Andrew Eisenberg [ 28/Sep/12 ]

Yep. This is exactly the same issue as GRECLIPSE-1355. Closing this one as a duplicate, follow the other issue instead.





[GRECLIPSE-1487] Save "silently" fails and leave buffer dirty Created: 31/Aug/12  Updated: 18/Oct/12  Resolved: 05/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Critical
Reporter: Marc Paquette Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

2.7.1.xx-20120824-0800-e37


Number of attachments : 0

 Description   

Sometimes, saving a buffer does not complete, leaving the buffer dirty (i.e. with a * in front of its name).

The original modifications made by user are getting commited to disk, but the modifications incurred by "organize import" save actions are not. Furthermore, the organized import corrupted the import list, removing some import statements for classes that are still in use in the class.



 Comments   
Comment by Marc Paquette [ 31/Aug/12 ]

I have no scientific evidences, but it looks a little bit like if there was some kind of race conditions going on between the rebuild of the compiler's internal structures (the AST I suppose) and the organize import save action. For example, I have a class named "com.accovia.infra.utilities.DateUtil" which routinely disapears from the import list as if the organize import ran while the AST was incomplete and didn't find a reference to that class and thus removed the import. Again, I am probably off base here, but it looks like something weird like that is going on.

Also, I noticed another class which is often victim of preemtive eviction from the import list : com.accovia.infra.exception.Error; I wonder if it has something to do the terminal class name being the same as java.lang.Error ?

Comment by Andrew Eisenberg [ 31/Aug/12 ]

Do you have save actions enabled (eg- organize imports on save and format on save)?

If you disable, do you still see the problem?

Comment by Marc Paquette [ 31/Aug/12 ]

Yes, I have organize imports in my save actions. Will disable them and report back.

Comment by Andrew Eisenberg [ 31/Aug/12 ]

My guess is that there is something odd about the file that you are using. Can you share the project with me? You can send it to my personal email. If not, could you share the file that is giving you the problems? Or, even better, can you whittle this down to a small example that I can try?

Comment by Marc Paquette [ 05/Sep/12 ]

Unfortunately, I cannot share the code with you. I haven't yet found the time to narrow it down to a simple reproductible case.

However, with "organize imports" turned off in save actions, everything is fine.

Comment by Andrew Eisenberg [ 05/Oct/12 ]

@Marc, unless you can provide a way to reproduce, I will be resolving this issue. I think there is something about the way that the imports are specified that is causing this bug, but without more information there is not much I can do

Comment by Mauro Molinari [ 18/Oct/12 ]

Maybe the source of this problem is the same as GRECLIPSE-1423.





[GRECLIPSE-1486] per-project compiler level property should allow for "Don't care" Created: 30/Aug/12  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Project Settings
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Version 2.7.1 introduced a project compiler setting that adds a build path error if the project and workspace compiler levels don't match.

We should also have a setting for specifying that the project doesn't care which compiler level to use.



 Comments   
Comment by Andrew Eisenberg [ 04/Apr/13 ]

Done. See GRECLIPSE-1606.





[GRECLIPSE-1485] Hang in Open Type Created: 27/Aug/12  Updated: 31/Jan/13  Resolved: 31/Jan/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Jeff Winkler Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows, java.version=1.7.0_04, java.vm.name=Java HotSpot(TM) 64-Bit Server VM


Number of attachments : 0

 Description   

I went to do a "Go to Type", and got a hang. Deadlock gettintg the Grails Console. This is in GGTS. Versions:

  Groovy-Eclipse Feature	2.7.1.xx-20120824-0800-e42	org.codehaus.groovy.eclipse.feature.feature.group	Codehaus.org
    Groovy Compiler 1.7.10 Feature	2.7.1.xx-20120824-0800-e42	org.codehaus.groovy17.feature.feature.group	Codehaus.org
    Groovy Compiler 1.8 Feature	2.7.1.xx-20120824-0800-e42	org.codehaus.groovy18.feature.feature.group	Codehaus.org
    Groovy-Eclipse Headless Feature	2.7.1.xx-20120824-0800-e42	org.codehaus.groovy.headless.feature.feature.group	Codehaus.org
    JDT Core patch for Groovy-Eclipse plugin	2.7.1.xx-20120824-0800-e42	org.codehaus.groovy.jdt.patch.feature.group	Codehaus.org
  Groovy/Grails Tool Suite	3.0.0.201207050802-M3-e42	com.springsource.ggts.ide	null
"Worker-80" prio=6 tid=0x000000001a821800 nid=0x998 waiting for monitor entry [0x0000000032d0e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at grails.build.logging.GrailsConsole.getInstance(GrailsConsole.java:242)
	- waiting to lock <0x000000006360cc68> (a java.lang.Class for grails.build.logging.GrailsConsole)
	at org.codehaus.groovy.grails.cli.logging.GrailsConsoleErrorPrintStream.println(GrailsConsoleErrorPrintStream.java:59)
	at java.lang.Throwable$WrappedPrintStream.println(Unknown Source)
	at java.lang.Throwable.printStackTrace(Throwable.java:654)
	- locked <0x0000000046390000> (a org.codehaus.groovy.grails.cli.logging.GrailsConsoleErrorPrintStream)
	at java.lang.Throwable.printStackTrace(Throwable.java:642)
	at java.lang.Throwable.printStackTrace(Throwable.java:633)
	at org.eclipse.jdt.internal.compiler.Compiler.handleInternalException(Compiler.java:668)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.handleInternalException(CompilationUnitResolver.java:364)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1245)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:712)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1181)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:807)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:544)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:537)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:480)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
	- locked <0x0000000064abcf88> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

   Locked ownable synchronizers:
	- None


"main" prio=6 tid=0x000000000245e000 nid=0x13a0 waiting for monitor entry [0x000000000285b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at grails.build.logging.GrailsConsole.getInstance(GrailsConsole.java:242)
	- waiting to lock <0x000000006360cc68> (a java.lang.Class for grails.build.logging.GrailsConsole)
	at org.codehaus.groovy.grails.cli.logging.GrailsConsoleErrorPrintStream.println(GrailsConsoleErrorPrintStream.java:59)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyErrorCollectorForJDT.addErrorAndContinue(GroovyErrorCollectorForJDT.java:34)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.addError(ClassCodeVisitorSupport.java:149)
	at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:287)
	at org.codehaus.groovy.control.ResolveVisitor.visitAnnotations(ResolveVisitor.java:1290)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:48)
	at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1447)
	at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:200)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:752)
	at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:677)
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:940)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:612)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:561)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1994)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:980)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody0(CompilationUnitProblemFinder.java:201)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody1$advice(CompilationUnitProblemFinder.java:244)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:1)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:319)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
	at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
	at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:159)
	at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog.setResult(FilteredTypesSelectionDialog.java:456)
	at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog.computeResult(FilteredItemsSelectionDialog.java:1044)
	at org.eclipse.ui.dialogs.SelectionStatusDialog.okPressed(SelectionStatusDialog.java:145)
	at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog.okPressed(FilteredItemsSelectionDialog.java:1061)
	at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:472)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
	at org.eclipse.jface.window.Window.open(Window.java:801)
	at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog.open(FilteredTypesSelectionDialog.java:509)
	at org.eclipse.jdt.internal.ui.actions.OpenTypeAction.runWithEvent(OpenTypeAction.java:80)
	at org.eclipse.jdt.internal.ui.actions.OpenTypeAction.runWithEvent(OpenTypeAction.java:162)
	at org.eclipse.ui.internal.handlers.ActionDelegateHandlerProxy.execute(ActionDelegateHandlerProxy.java:287)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
	at sun.reflect.GeneratedMethodAccessor144.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
	at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1521)
	at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640)
	at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4528)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4976)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

   Locked ownable synchronizers:
	- None


 Comments   
Comment by Andrew Eisenberg [ 27/Aug/12 ]

It looks like you have a grails command that is hanging. But, I can't be certain since the entire jstack contents are not included.

Are you able to reliably reproduce this?

If this happens again, can you run jstack from the command line, save the contents to a file and attach the file to this issue?

Comment by Jeff Winkler [ 27/Aug/12 ]

I can't seem to reproduce it. However, I was running VisualVM and confirmed there was no external Grails process.... it would show up as a very obvious GrailsStarter entry in VisualVM. If it happens again I'll grab all the threads. FWIW, I do have InfiniTest running tests in the background.

But, isn't Worker-80 the GUI updating its state - nothing to do with Grails?

	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
Comment by Andrew Eisenberg [ 05/Oct/12 ]

On a deeper look, it seems like the editor and the open type dialog are trying to resolve some types, but finding an error. They are both trying to log this error to the GrailsConsole (which really would be a no-op since this is not a real compile, only a resolve), but something else already has a lock on the GrailsConsole class. This could be a call to Refresh dependencies, or a grails process that is finishing up. Hard to know without seeing more data.

Comment by Andrew Eisenberg [ 31/Jan/13 ]

Assuming cannot reproduce. Please comment if you see this again.





[GRECLIPSE-1483] Type inferencing for field initializers Created: 27/Aug/12  Updated: 10/Jul/14  Resolved: 10/Jul/14

Status: Closed
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.7.0.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Unassigned
Resolution: Won't Fix  
Labels: stability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As described in GRECLIPSE-1482, field initializers are not contributing to type inferencing. For example:

class Foo {
  def x = 9
}
new Foo().x

I would expect the type of x to be inferred to Integer, but it is not.



 Comments   
Comment by Denis Murashev [ 10/Jul/14 ]

Type inference should not work for fields with type 'def', because any thread can change it at any time.





[GRECLIPSE-1482] Groovy Editor Autocomplete problems. Created: 27/Aug/12  Updated: 27/Aug/12  Resolved: 27/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Editor
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Sergey Kolesnikov Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64
Spring Tool Suite 3.x - 2.x
Groovy Eclipse Plugin 2.7
Groovy Compiler 1.8 - 2.0


Number of attachments : 0

 Description   

First issue

I have a next class

Bar.java
package com.db.fim.mr.faaws

import groovy.sql.Sql;


class BaseSpec {

    def sql = Sql.newInstance("jdbc:h2:mem:test", "org.h2.Driver")
	

    def setupSpec() {
	sql.execute("my command"); 
    }
}

Groovy editor can't see sql variable methods besides DefaultGroovyMethods category, so i see execute method as unknow.
When i run Groovy Type Checking it shows next error for this : Type of expression is statically unknown: execute.
This code works well when i run it.

Note, that code completion in Intellij Idea shows it right.

But if i modify my class, and set static type for sql variable :

Bar.java
package com.db.fim.mr.faaws

import groovy.sql.Sql;


class BaseSpec {

    def Sql sql = Sql.newInstance("jdbc:h2:mem:test", "org.h2.Driver")
	

    def setupSpec() {
	sql.execute("my command"); 
    }
}

Then there is no more error here.
It seems that problem in dynamic type definition for sql variable.

Second issue

Steps to reproduce:
1. Type
def myMap = new HashM
2. Press Ctrl + Space and select java.util.HashMap(Groovy) to autocomplete
3. See result
def myMap = new HashMap<K, V>()
4. Edit K, and type Inte
5. Press Ctrl + Space to autocomplete.

Expected result : see list of classes, and availability to select, for instance, Integer class.

Actual result : in autocomplete list we see only available HashMap constructors.

Please, fix it as soon as posible. Thanks.



 Comments   
Comment by Andrew Eisenberg [ 27/Aug/12 ]

These are two separate issues and so it would be better to raise two separate issues for them. I'll explore a bit and see what is going on here.

Comment by Andrew Eisenberg [ 27/Aug/12 ]

Separated into 2 issues: GRECLIPSE-1483 and GRECLIPSE-1484.





[GRECLIPSE-1481] use of list construct breaks formatting Created: 24/Aug/12  Updated: 02/Oct/12  Resolved: 02/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Tom Nelson Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Red hat 6.1 eclipse 3.7


Number of attachments : 0

 Description   

The line commented below breaks formatting, past it into eclipse and try it yourself. {{String[] k = ['a','b'] }} also breaks formatting

          
class ShowFormatBug {

    def f() {
        xyz
    }

    def k(List l) {
        def qrs
    }

    def l() {
        //            k([])  // THIS LINE BREAKS ECLIPSE FORMATTING
    }
}


 Comments   
Comment by Tom Nelson [ 24/Aug/12 ]

My entry was formatted above so to clarify, the key is that [] seems to break formatting, so k([]) breaks it, but when it is commented it starts working. Is there a workaround? Can I down grade to an earlier version?

Comment by Tom Nelson [ 24/Aug/12 ]

Even def z = [] breaks formatting.

Comment by Lari Hotari [ 26/Sep/12 ]

This issue duplicates GRECLIPSE-1476 . I hope that gets fixed ASAP. Please vote!

Comment by Andrew Eisenberg [ 02/Oct/12 ]

Now working due to recent changes in GRECLIPSE-1427 and GRECLIPSE-1478.





[GRECLIPSE-1480] GroovyEdditor throwing exceptions if project nature is not Java project nature Created: 24/Aug/12  Updated: 24/Aug/12  Resolved: 24/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Project Settings
Affects Version/s: None
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: cyriel Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: eclipse, exception, plugin
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows xp sp 3, eclipse - Juno Release Build id: 20120614-1722, GroovyEditor 2.7.0(propably this bug occurs in all versions)


Attachments: Zip Archive bugTestExported.zip    
Number of attachments : 1

 Description   

Generally the problem sie quite simple - if you are using GroovyEditor in project with Java nature everthing is fine, if project nature is diffrent(or there is no project nature) each time you type something in GroovyEditor exception is thrown. It's already described here - http://groovy.329449.n5.nabble.com/Bug-in-GroovyEditor-td5711008.html
File included here is simple plugin project in which this issue occurs. It's described in topic on groovy->groovy-dev(link above) forum.



 Comments   
Comment by Andrew Eisenberg [ 24/Aug/12 ]

Fixed. Now no longer displaying error message when compilation unit not in a java project.





[GRECLIPSE-1479] Syntax coloring *insists* on italic function names Created: 19/Aug/12  Updated: 19/Aug/12  Resolved: 19/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Patrick Turley Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Juno Eclipse platform

Groovy Eclipse plugin 2.7.0.xx-20120703-1400-e42-RELEASE


Attachments: PNG File Italics.png    
Number of attachments : 1

 Description   

I downloaded Eclipse Juno and installed the Groovy plugin.

I removed all italic elements from the Java syntax highlighting options.

I copied Java syntax highlighting to Groovy syntax highlighting options.

I looked over the Groovy syntax highlighting options and assured myself that it wasn't even possible to specify italics.

As you can see in the attached screen shot, function names are still italicized.

One of the following seems possible to me:

  1. I missed a check box somewhere, but it's still a bug because I've looked in all the places that check box should be.

  2. The plugin is mistakenly forcing some syntax elements to be highlighted (I haven't gotten very far in my work, so function names may not be the only thing that's broken).


 Comments   
Comment by Andrew Eisenberg [ 19/Aug/12 ]

Static methods by default are italicized. You can change this in either of two ways:

  1. Go to Preferences -> Groovy -> Editor. Scroll to the bottom and uncheck "Enable semantic highlighting..."
  2. Go to Preferences -> Groovy -> Editor. Scroll to the bottom and click on the hyperlink to go to the Java syntax coloring page. In that preference page, find the item for static method invocations and deselect italics.

Note that the first option affects groovy code only and the second option affects java and groovy code.

Comment by Andrew Eisenberg [ 19/Aug/12 ]

Unless there's something unexpected here, I don't see any bug so resolving this issue.





[GRECLIPSE-1478] Unexpected identation of method arguments multiline declaration Created: 10/Aug/12  Updated: 02/Oct/12  Resolved: 02/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.7.0.Release, 2.7.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Alex Abdugafarov Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP3


Number of attachments : 0

 Description   

Formatting/identing

class A {
def method(
def arg1,
def arg2
){
// method body
}
}

leads to

class A {
    def method(
    def arg1,
    def arg2
    ){
        // method body
    }
}

Expected result:

class A {
    def method(
        def arg1,
        def arg2
    ){
        // method body
    }
}


 Comments   
Comment by Andrew Eisenberg [ 28/Sep/12 ]

This one is unrelated to GRECLIPSE-1476.

Comment by Andrew Eisenberg [ 28/Sep/12 ]

I'll try for this in 2.7.2.

Comment by Andrew Eisenberg [ 28/Sep/12 ]

I think I have a fix for this, but need to create some more tests. The fix I have would also handle similar situations with if, while, and for statements.

eg-

if (a &&
b &&
c
) { 
}

becomes:

if (a &&
  b &&
  c
) { 
}

Personally, I would always keep the closing paren on the same line as the last parameter declaration, but if it's not on the same line, then it makes sense to unindent.

Comment by Andrew Eisenberg [ 28/Sep/12 ]

Spoke too soon. There are some situations that still need to be cleaned up. Next week.

Comment by Andrew Eisenberg [ 02/Oct/12 ]

Fixed this issue (and this issue only). There were a bunch of competing strategies all mixed up together and in the end I couldn't make as general a fix as I would have liked.

I raised GRECLIPSE-1507 to deal with the formatting of if statements described above.

Fix for this will be available in next snapshot build.





[GRECLIPSE-1476] Square brackets list causes formatter to stop formatting Created: 10/Aug/12  Updated: 03/Oct/12  Resolved: 28/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I would expect that formatting this:

		[[], [var1], [var1, var2]]
		def x

would lead to this:

[[], [var1], [var1, var2]]
def x

but there is no change.



 Comments   
Comment by Lari Hotari [ 26/Sep/12 ]

Please fix this problem. This is an annoying problem.

GRECLIPSE-1481 seems to be a duplicate.

Comment by Lari Hotari [ 26/Sep/12 ]

These issues might be related: GRECLIPSE-1488 and GRECLIPSE-1355 (about list formatting)

Comment by Andrew Eisenberg [ 28/Sep/12 ]

I'll take a look at this.

Comment by Lari Hotari [ 28/Sep/12 ]

Great, I'm looking forward for the fix. This problem is really annoying in STS 3.0 with latest stable Greclipse (2.7.1).
I'm not sure if it's the same problem but auto-indent stops working at least for some Groovy files which contain square brackets.

Comment by Alex Abdugafarov [ 28/Sep/12 ]

Finally, thanks for your attention. This, along with GRECLIPSE-1478, renders autoformatting useless, if not harmful.

Comment by Andrew Eisenberg [ 28/Sep/12 ]

I have a fix for this. Looks like an exception was being thrown and swallowed. The formatter tokens were being disposed of too early. This is fixed and the example above now works (along with many other similar examples).

Comment by Andrew Eisenberg [ 28/Sep/12 ]

Will be available in next snapshot build.

Comment by Lari Hotari [ 03/Oct/12 ]

Thanks for the fix. I tested the snapshot build but now annotations on methods cause an extra indent.

Test formatting with this example

import org.junit.Ignore

class SomeClass {
   @Ignore
   public void doSomething() {

   }
}
Comment by Alex Abdugafarov [ 03/Oct/12 ]

@Lari Hotari
Worked fine with your example, but failed with this one (i'm using tabs for identing):

import org.junit.Ignore

class SomeClass {
	@Ignore
			public void doSomething(String a) {
	}
}

Created an issue for that: GRECLIPSE-1508

Comment by Andrew Eisenberg [ 03/Oct/12 ]

Yep. Just been reported. See GRECLIPSE-1508.





[GRECLIPSE-1475] Pressing enter inside of curly braces pair should place closing brace on next line and uninented Created: 09/Aug/12  Updated: 09/Aug/12  Resolved: 09/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Formatting
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider this text. where | represents the caret:

if (foo) {|}

In the java editor, pressing enter would produce this:

if (foo) {
  |
}

But in the Groovy editor, it does this:

if (foo) {
  |}

Very annoying.



 Comments   
Comment by Andrew Eisenberg [ 09/Aug/12 ]

Fixed with regression tests.





[GRECLIPSE-1474] After updating GRECLIPSE from 2.7.0 to 2.7.1, the groovy 1.7.x compiler level isn't supported any more Created: 06/Aug/12  Updated: 09/Aug/12  Resolved: 09/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.7.1.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Critical
Reporter: Torben Riis Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64bit, SpringSource Tool Suite 2.9.1


Attachments: JPEG File screen.jpg    
Number of attachments : 1

 Description   

After updating GRECLIPSE from 2.7.0 to 2.7.1, the groovy 1.7.x compiler level isn't working any more.
Opening groovy files results in the below error.

java.lang.NoClassDefFoundError: org/codehaus/groovy/runtime/BytecodeInterface8
	at org.codehaus.groovy.eclipse.editor.highlighting.HighlightingExtenderRegistry.getAdditionalRulesForProject(HighlightingExtenderRegistry.groovy)
	at org.codehaus.groovy.eclipse.editor.GroovyConfiguration.createTagScanner(GroovyConfiguration.java:76)
	at org.codehaus.groovy.eclipse.editor.GroovyConfiguration.<init>(GroovyConfiguration.java:65)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.createJavaSourceViewerConfiguration(GroovyEditor.java:1261)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.setPreferenceStore(GroovyEditor.java:654)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput(JavaEditor.java:2535)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput(CompilationUnitEditor.java:1395)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.doSetInput(GroovyEditor.java:1019)
	at org.eclipse.ui.texteditor.AbstractTextEditor$19.run(AbstractTextEditor.java:3200)
	at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
	at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756)
	at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2649)
	at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:3218)
	at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:3245)
	at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:828)
	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:647)
	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:313)
	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:180)
	at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:270)
	at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
	at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:473)
	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1245)
	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1198)
	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1597)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:493)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:479)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:225)


 Comments   
Comment by Torben Riis [ 06/Aug/12 ]

Further investigation showed that it was an update from 2.7.1.xx-20120720-1000-e37 to 2.7.1.xx-20120803-1100-e37 and not from 2.7.0...
It should also me mentioned that the error does not occurs if the compiler is set 1.8.x.

Comment by Andrew Eisenberg [ 07/Aug/12 ]

I'll have to investigate this, but it is probably happening because we are now compiling Groovy-Eclipse with a Groovy 1.8 compiler. This is related to moving to the new build server.

The problem is that code compiled by groovy 1.8 cannot be run with a Groovy 1.7 runtime.

Comment by Andrew Eisenberg [ 07/Aug/12 ]

I just pushed a fix that should force the build server to use Groovy 1.7 to compile.

Comment by Andrew Eisenberg [ 07/Aug/12 ]

That fix didn't work. Trying something else.

Comment by Andrew Eisenberg [ 08/Aug/12 ]

Now it is working for me. Please update to the latest snapshot and let me know if you are seeing the same.

Comment by Torben Riis [ 08/Aug/12 ]

Confirmed, it is working as intended now. Thanks a lot.

Comment by Andrew Eisenberg [ 09/Aug/12 ]

Resolving. Thanks for confirming the fix.





[GRECLIPSE-1472] Problem with @CompileStatic and generics Created: 05/Aug/12  Updated: 11/Oct/12  Resolved: 07/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following:

A.groovy
package a

import groovy.transform.CompileStatic

@CompileStatic
class A extends B {
	public a() {
		b(['now': new Date()])
	}
}

and:

B.groovy
package a

abstract class B {
	public b(Map<String, ?> map) {
	}
}

An error is given on B.b invocation in A:

Groovy:[Static type checking] - Cannot find matching method a.A#b(java.util.Map <java.lang.String, java.util.Date>)


 Comments   
Comment by Andrew Eisenberg [ 07/Aug/12 ]

Please update to the latest nightly. This problem should be fixed there.
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

Comment by Mauro Molinari [ 11/Oct/12 ]

Yes, I confirm this is fixed in 2.7.1, thank you.





[GRECLIPSE-1470] Problem configuring groovy classloader classpath (not using groovy.properties) Created: 26/Jul/12  Updated: 03/Oct/12  Resolved: 07/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Jörg Thönnes Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File .classpath     Text File Eclipse-stacktrace.txt     File .project    
Number of attachments : 3

 Description   

Eclipse continues to show this output on stdout:

Problem configuring groovy classloader classpath (not using groovy.properties)
java.lang.NullPointerException
	at org.eclipse.jdt.core.util.CompilerUtils.pathToString(CompilerUtils.java:194)
	at org.eclipse.jdt.core.util.CompilerUtils.calculateClasspath(CompilerUtils.java:210)
	at org.eclipse.jdt.core.util.CompilerUtils.setGroovyClasspath(CompilerUtils.java:152)
	at org.eclipse.jdt.core.util.CompilerUtils.setGroovyClasspath(CompilerUtils.java:117)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:260)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
	at org.eclipse.jdt.internal.core.BecomeWorkingCopyOperation.executeOperation(BecomeWorkingCopyOperation.java:38)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
	at org.eclipse.jdt.internal.core.CompilationUnit.becomeWorkingCopy(CompilationUnit.java:101)
...


 Comments   
Comment by Jörg Thönnes [ 26/Jul/12 ]

Attached complete Eclipse stack trace output.

This occurs several times.

Comment by Jörg Thönnes [ 26/Jul/12 ]

Eclipse version 3.7.2 with Mylyn 3.8, GRECLIPSE 2.7.0

Comment by Andrew Eisenberg [ 26/Jul/12 ]

I can definitely add a null check to avoid this NPE, but I'd prefer to figure out what the cause of the problem is. Do you know which project is causing the exception? Can you attach the .project file and the .classpath file for this project? (They are hidden files in the root of the project.)

Comment by Jörg Thönnes [ 01/Aug/12 ]

Hello Andrew,

sorry for answering so late – was busy and will be unavailable for the next 3 weeks.

Please find attached the .classpath and .project files.

Cheers, Jörg

Comment by Jörg Thönnes [ 01/Aug/12 ]

Attached .project file.

Comment by Jörg Thönnes [ 01/Aug/12 ]

If you have any questions – I might check this ticket for the next 2-3 days.

Comment by Andrew Eisenberg [ 01/Aug/12 ]

Thanks for the extra attachments.

It looks like the only way there can be an NPE at CompilerUtils.java:194 is if the project is closed or doesn't exist. If this is the case, then I'm not sure why the file is being sent to the compiler. I see from the stack trace that this exception occurred while in the compare editor. Perhaps you somehow have an editor open that is trying to compare a file that is located in a closed project. This is just a hunch. Is this something that makes sense to you?

I will add the null check and commit it.

Comment by Andrew Eisenberg [ 02/Aug/12 ]

I committed a null pointer check that should hopefully avoid the NPE that you are seeing. My assumption, as I mentioned in my previous comment is that the project that is causing this error is either closed or deleted even though you have an editor still open with the file you are working on.

Comment by Andrew Eisenberg [ 02/Aug/12 ]

New build is available for 3.7 and 4.2. Please update using the snapshot update site when you can and provide feedback if this is working for you.

Comment by Jörg Thönnes [ 03/Aug/12 ]

Thanks, Andrew. I am on vacation now and will be able to check in 3 weeks.

Comment by Andrew Eisenberg [ 03/Aug/12 ]

Thanks. Please keep us posted.

Comment by Jörg Thönnes [ 07/Sep/12 ]

Sorry, Andrew for not responding timely. I was on holiday and in the meanwhile we have upgraded our installation to Eclipse 3.8.

If I see this issue again (did not happen since I reported it), I will test with the snapshot provided by you.

Comment by Andrew Eisenberg [ 07/Sep/12 ]

Closing this issue for now. But I will reopen if you experience again.

Comment by Rafael Chaves [ 03/Oct/12 ]

I can reproduce this reliably on a new workspace with a new Grails project using Groovy/Grails Tool Suite 3.0.0.RELEASE (Build Id: 201208091018),

Andrew, do you know if your fix got in that build?

Steps to reproduce:
1) on a grails project, show the local history for a Groovy file (if there is no history yet, make some edits, save and try again)
2) in the history view, right click one of the entries and select "Compare Current with Local" (make sure you didn't have the compare editor open for that file)

Comment by Andrew Eisenberg [ 03/Oct/12 ]

This fix did not make it into GGTS 3.0.0, which included Groovy-Eclipse 2.7.0. You can upgrade to 2.7.1 from the update site:

http://dist.springsource.org/release/GRECLIPSE/e4.2/

I think it is included in GGTS by default.

I tried your steps on the latest snapshot and could not reproduce. If you still see this problem after upgrading, then I will have a deeper look.

Comment by Rafael Chaves [ 03/Oct/12 ]

Thanks. At least now you know how the problem would have occurred. I confirmed the issue doesn't happen in 2.7.1.

Comment by Andrew Eisenberg [ 03/Oct/12 ]

Thanks for verifying the fix. And now that I think about it a bit, this makes sense based on the original implementation. We had expected that we would always be compiling a file (or at least something traceable to disk). In this case, however, we are trying to compile a diff-ed version. And so we cannot configure the groovy classloader in the same way. The fix makes sense as I see it.





[GRECLIPSE-1469] Contributed method with named parameters and a closure parameter should always put closure at the end Created: 25/Jul/12  Updated: 25/Jul/12  Resolved: 25/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, DSL Support
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, when a contributed method has both named and regular parameters, and the last regular parameter is a closure, the closure is placed in the middle of the parameter list. Eg-

dsld:

contribute(currentType()) {
  method name:'flart', params:[op: Closure], namedParams:[other:String]
}

script

flar<>

Content assist at flar will give you:

flart({, other:"")

This is wrong. It should be this:

flart(other:"") {


 Comments   
Comment by Andrew Eisenberg [ 25/Jul/12 ]

Fixed, but not pushed. Waiting until after STS 3.0 is released.

Comment by Andrew Eisenberg [ 25/Jul/12 ]

Just to be clear. We are now handling all closure parameters properly. Closure parameters that occur in the middle of a parameter chain is provided as a full closure, like this: { }.

So:

dsld:

contribute(currentType()) {
  method name:'flart', params:[op: Closure,op2: Closure], namedParams:[other:String]
}

script

flar<>

Content assist at flar will give you:

flart({ }, other:"") {




[GRECLIPSE-1468] NPE thrown on new Groovy class wizard when specifying an interface and checking the "inherit abstract methods" box Created: 25/Jul/12  Updated: 18/Oct/12  Resolved: 08/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to GRECLIPSE-1519 Intermittent hang when entering/editi... Resolved
is related to GRECLIPSE-1433 Intermittent editor error when editin... Resolved
is related to GRECLIPSE-1452 Save Failed with AssertionFailedExcep... Resolved
Number of attachments : 0

 Description   

NPE thrown in the groovy class wizard when specifying an interface and checking the "Inherited abstract methods" box.

java.lang.reflect.InvocationTargetException
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:421)
	at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1028)
	at org.eclipse.jdt.internal.ui.wizards.NewElementWizard.performFinish(NewElementWizard.java:134)
	at org.codehaus.groovy.eclipse.wizards.NewClassWizard.performFinish(NewClassWizard.java:72)
	at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:827)
	at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:432)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4134)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1271)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3980)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3619)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
	at org.eclipse.jface.window.Window.open(Window.java:801)
	at org.eclipse.ui.internal.handlers.WizardHandler$New.executeHandler(WizardHandler.java:259)
	at org.eclipse.ui.internal.handlers.WizardHandler.execute(WizardHandler.java:279)
	at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1072)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4133)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1495)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1491)
	at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:493)
	at org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1060)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5585)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
	at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5495)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:221)
	at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2102)
	at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2284)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5557)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:5002)
	at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5151)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3616)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
Caused by: java.lang.NullPointerException
	at org.eclipse.jdt.internal.corext.dom.ASTNodes.getParent(ASTNodes.java:518)
	at org.eclipse.jdt.internal.corext.dom.ASTNodes.getTypeBinding(ASTNodes.java:947)
	at org.eclipse.jdt.ui.wizards.NewTypeWizardPage.createInheritedMethods(NewTypeWizardPage.java:2586)
	at org.eclipse.jdt.ui.wizards.NewClassWizardPage.createTypeMembers(NewClassWizardPage.java:255)
	at org.codehaus.groovy.eclipse.wizards.NewClassWizardPage.createTypeMembers(NewClassWizardPage.java:83)
	at org.eclipse.jdt.ui.wizards.NewTypeWizardPage.createType(NewTypeWizardPage.java:2141)
	at org.codehaus.groovy.eclipse.wizards.NewClassWizardPage.createType(NewClassWizardPage.java:164)
	at org.codehaus.groovy.eclipse.wizards.NewClassWizard.finishPage(NewClassWizard.java:64)
	at org.eclipse.jdt.internal.ui.wizards.NewElementWizard$2.run(NewElementWizard.java:118)
	at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5204)
	at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Root exception:
java.lang.NullPointerException
	at org.eclipse.jdt.internal.corext.dom.ASTNodes.getParent(ASTNodes.java:518)
	at org.eclipse.jdt.internal.corext.dom.ASTNodes.getTypeBinding(ASTNodes.java:947)
	at org.eclipse.jdt.ui.wizards.NewTypeWizardPage.createInheritedMethods(NewTypeWizardPage.java:2586)
	at org.eclipse.jdt.ui.wizards.NewClassWizardPage.createTypeMembers(NewClassWizardPage.java:255)
	at org.codehaus.groovy.eclipse.wizards.NewClassWizardPage.createTypeMembers(NewClassWizardPage.java:83)
	at org.eclipse.jdt.ui.wizards.NewTypeWizardPage.createType(NewTypeWizardPage.java:2141)
	at org.codehaus.groovy.eclipse.wizards.NewClassWizardPage.createType(NewClassWizardPage.java:164)
	at org.codehaus.groovy.eclipse.wizards.NewClassWizard.finishPage(NewClassWizard.java:64)
	at org.eclipse.jdt.internal.ui.wizards.NewElementWizard$2.run(NewElementWizard.java:118)
	at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5204)
	at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)


 Comments   
Comment by John Bito [ 25/Jul/12 ]

I would add that this exception was encountered in an Eclipse session after an unusual failure in which the editor (silently) could not s save a different class file. The earlier problem was with a class that had been moved from one package to another; the source package deleted was deleted after the move.

Comment by Andrew Eisenberg [ 25/Jul/12 ]

I was able to reproduce this exception myself without the previous problem that you had, so I am not sure that they are related.

Comment by Andrew Eisenberg [ 26/Jul/12 ]

This is turning out to be way more complicated than I thought. It looks like the problem is happening because the java model file buffer org.eclipse.jdt.core.IBuffer for GroovyCompilationUnits are discarded whenever an unknown type is found in the source. Here are the steps that happens. Eg-

class A implements B { }  // B doesn't exist
  1. Groovy tries to resolve B in a number of ways
  2. one of the ways it tries to resolve B is as an inner type (ie- A$B).
  3. When trying to resolve A$B, a SearchableEnvironment (line 120) calls getElementInfo on the IType for B. It is found that B doesn't exist.
  4. The buffer is closed.
  5. Now, inside of an editor, problems aren't typically manifested. When the buffer is closed, it can be reopened again on the next operation. Changes to the buffer are not lost since there is another, lower-level buffer org.eclipse.core.internal.filebuffers.ResourceFileBuffer that remains open since the editor also has a link to it.
  6. The problem comes about in the wizard since the org.eclipse.core.internal.filebuffers.ResourceFileBuffer only has one reference and that is coming from the org.eclipse.jdt.core.IBuffer that is being created.
  7. When an undefined type is encountered, the org.eclipse.jdt.core.IBuffer is closed and this in turn closes the org.eclipse.core.internal.filebuffers.ResourceFileBuffer and the entire contents is lost, causing havoc.

Even though no problems occur in the editor, this behavior is not correct and may be leading to bugs like GRECLIPSE-1433 and GRECLIPSE-1452.

I don't know the best way to fix this, but I would guess that the problem comes down to how the JDTResolver will try to locate types inside of the current type even if they are known not to exist. At the point of the resolve, the structure of the current working copy is already known. So, before trying to look for a type through the SearchableEnvironment, the current CompilationUnit should be targetted first.

Comment by Andrew Eisenberg [ 27/Jul/12 ]

I think that fixing this bug will also address GRECLIPSE-1433 and GRECLIPSE-1452.

Comment by Andrew Eisenberg [ 27/Jul/12 ]

New snapshot build is available that fixes this problem and maybe even GRECLIPSE-1433 and GRECLIPSE-1452. Please try this out and let me know if your problems are addressed.

Comment by John Bito [ 27/Jul/12 ]

Works for me, now (in Version: 2.7.1.xx-20120727-1400-e42)!

Comment by Andrew Eisenberg [ 28/Jul/12 ]

Thanks for getting back to me on this. I'm going to leave this open for a bit longer to make sure that you are not getting any other exceptions like we talked about before.

Comment by Andrew Eisenberg [ 08/Aug/12 ]

Assuming fixed. Please comment again if you see any similar problems.





[GRECLIPSE-1467] Autoboxing not working with @CompileStatic Created: 25/Jul/12  Updated: 11/Oct/12  Resolved: 25/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Daniel Gredler Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy compiler version 2.0.0.xx-20120703-1400-e42-RELEASE


Number of attachments : 0

 Description   

The following code, which requires autoboxing, works fine on the command line with Groovy 2.0.0:


@groovy.transform.CompileStatic
def test() {
    double d1 = 2
    Double d2 = d1
    println d2
}

test()

However, it doesn't seem to work in Eclipse with the Groovy plugin. I get the following compile error:

Groovy:[Static type checking] - Cannot assign value of type double to variable of type java.lang.Double

I would have expected this code to work both on the command line and in Eclipse, or to not work in either place, but apparently it's only the plugin that's broken?



 Comments   
Comment by Andrew Eisenberg [ 25/Jul/12 ]

Thanks for the bug report. I reproduced this in the 2.7.0 release and verified that this is fixed in the 2.7.1 snapshots. Please upgrade to the latest nightly and you should see this fixed.

Use this update site:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
or
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e4.2/





[GRECLIPSE-1466] Better content assist for annotations Created: 18/Jul/12  Updated: 19/Jul/12  Resolved: 19/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It would be nice if groovy-eclipse only proposed annotation completions when in a location where annotations are allowed. Eg-

@C<>
class Foo { }

Completing at <> should only include annotation types, not classes, interfaces, or enums.



 Comments   
Comment by Andrew Eisenberg [ 19/Jul/12 ]

Fixed this, but putting it into a separate branch until after STS 3.0.0.RC1 is out.





[GRECLIPSE-1464] Groovy-Eclipse does not recognize an Extension Module defined in a jar in the classpath Created: 17/Jul/12  Updated: 11/Oct/12  Resolved: 03/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Blocker
Reporter: Chanwit Kaewkasi Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy 2.0, Eclipse Juno


Issue Links:
Supercedes
is superceded by GRECLIPSE-1471 Support Groovy 2's extension modules Open
Number of attachments : 0

 Description   

Groovy 2.0 supports a new mechanism called Extension Modules, which allow to have a user-defined extension for existing classes.

Using Gradle or Maven outside Eclipse, the compilation process works fine with an addition extension module. In the IDE, however, Groovy-Eclipse does not recognize the extension module. With @CompileStatic, it reported as an error preventing compilation and/or unit testing.



 Comments   
Comment by Chanwit Kaewkasi [ 17/Jul/12 ]

This bug also affects the snapshot of Groovy-Eclipse 2.7.1.

Comment by Andrew Eisenberg [ 18/Jul/12 ]

The relevant information is here:
http://docs.codehaus.org/display/GROOVY/Creating+an+extension+module

Comment by Andrew Eisenberg [ 03/Aug/12 ]

See GRECLIPSE-1471 for the resolution of this issue.





[GRECLIPSE-1463] Paste into Groovy editor causes hang on Juno Created: 16/Jul/12  Updated: 24/Aug/12  Resolved: 08/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Critical
Reporter: Steven Dick Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 SP1 64-bit
Eclipse EE 4.2 64-bit
Oracle JDK 7.0_03
Groovy compiler 1.8.6


Attachments: Text File greclipse-crash-20120802.txt    
Number of attachments : 1

 Description   

I've experienced the hang while pasting code as well as pasting text into a multi-line string. Eclipse freezes and needs to be killed.



 Comments   
Comment by Steven Dick [ 16/Jul/12 ]

I also had the hang while doing a cut operation.

Comment by Andrew Eisenberg [ 16/Jul/12 ]

That's unfortunate, but without more information, there's not much more I can do.

Can you attach a stack trace? Next time this happens, run jps and then jstack from the command line. Attach the full stack trace. Also, after a restart, you may see some relevant stack traces in the error log (Window -> Show view -> Other -> Error log). Attach them to this report as well.

Comment by Marco Ziech [ 02/Aug/12 ]

I am using Groovy Eclipse 2.7.0 on Juno and the IDE freezes frequently. I think I also experienced at least one freeze during a copy&paste operation, today it freezed during manual reformatting of some groovy code, though.

Maybe it is related, so I attached a stacktrace showing a deadlock. I couldn't find any helpful information in the error log. This is what it says on startup:

eclipse.buildId=I20120608-1400
java.version=1.7.0_03
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product
Comment by Andrew Eisenberg [ 02/Aug/12 ]

@Marco, thanks for the stack traces. I do see a deadlock. This will be helpful. I'll see what I can do with this.

Comment by Andrew Eisenberg [ 02/Aug/12 ]

I see exactly why this deadlock is happening. This is due to a change I made recently regarding the way that groovy modules are pushed into the Java model. I reorganized the relevant synchronized block so that the problematic code is not synchronized. The snapshot build is being created now and should be available in a few hours. I'll post a note here when it's ready.

Comment by Andrew Eisenberg [ 02/Aug/12 ]

New build is available for 3.7 and 4.2. Please update using the snapshot update site and provide feedback if this is working for you.

Comment by Marco Ziech [ 03/Aug/12 ]

Ok, I'm testing with 2.7.1.xx-20120802-0800-e42 right now. If I don't experience the same freeze in the next few days, I'll let you know.

Comment by Andrew Eisenberg [ 03/Aug/12 ]

Thanks. Please keep us posted.

Comment by Marco Ziech [ 08/Aug/12 ]

While developing with the snapshot the past few days I didn't experience any freezes. Before, the IDE was freezing about every 2 1/2 hours, now it runs for a whole day.

Therefore, I think the problem is fixed. Thanks!

Comment by Andrew Eisenberg [ 08/Aug/12 ]

Thanks for getting back to me. I am assuming this is now fixed, but please comment again if you continue to see the hanging.

Comment by Lari Hotari [ 24/Aug/12 ]

I think this is an old Eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=366048 .

I have disabled Java->Editor->Content Assist->Auto Activation and I don't experience the problem anymore.

Comment by Andrew Eisenberg [ 24/Aug/12 ]

Hi Lari, I don't think the issues are related. The issue originally posted here had to do with some changes in the way that groovy-eclipse caches module nodes. The module info lock was being grabbed too eagerly and that conflicted with another thread that had a file buffer lock.

The stack trace that you have in the bugzilla issue does not show any deadlocks and I see no groovy-related code.

It is interesting that two of the commenters on that bug were using STS. It might be a coincidence, but maybe not.

Comment by Lari Hotari [ 24/Aug/12 ]

Yes I noticed the difference in thread dumps after posting my comment here. Anyways, It might be helpful for someone else to find this information here. The symptom of bug #366048 fits the title of this issue "Paste into Groovy editor causes hang on Juno". In my case it hanged on copy and cut operations.

After upgrading to STS / GGTS 3.0 I was really struggling with this Eclipse bug #366048 and it showed up for me in the Groovy editor about 20 times before I found a workaround. It must have something to do with the Content Assist's auto activation since I haven't seen a single freeze after disabling that. It might not be an actual deadlock, but the UI freezes totally and requires killing STS. I'm glad I got the problem solved and I'm able to continue using STS 3.0 (+Groovy editor / greclipse).





[GRECLIPSE-1462] Archived Development builds 404 on website homepage Created: 10/Jul/12  Updated: 10/Jul/12  Resolved: 10/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Blocker
Reporter: Chris Lormor Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: build, web
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested on Windows XP/IE 7, and Mac OSX 10.7/Chrome


Number of attachments : 0

 Description   

I was not sure of the best way to raise this issue, so forgive me if this is inappropriate use of Jira.

The section of the project homepage (http://groovy.codehaus.org/Eclipse+Plugin) entitled Archived Development Builds lists several links to download zip files of archived update sites for various versions of eclipse.

Unfortunately these links are all broken. I am looking to use the plugin at a site with limited external connectivity, so the missing archive builds is blocking me from using the tool.

Thanks,

Chris
(GRECLIPSE fan)



 Comments   
Comment by Andrew Eisenberg [ 10/Jul/12 ]

Thanks for pointing that out. I'll fix the links right now.

Comment by Andrew Eisenberg [ 10/Jul/12 ]

Also, if you click on the New and Noteworthy links at the top, you will find some urls for the update sites of the releases.

Comment by Andrew Eisenberg [ 10/Jul/12 ]

I fixed the links. The archived development update sites are transient. They are typically deleted whenever the server needs more room. However, our releases will be available indefinitely. If the dev builds are not sufficient for you, then in each of our new and noteworthy pages, we have links to archived update sites. See here:

http://docs.codehaus.org/display/GROOVY/Eclipse+Plugin#EclipsePlugin-NewandNoteworthy





[GRECLIPSE-1459] type() pointcut not recognizing an empty parameter Created: 06/Jul/12  Updated: 06/Jul/12  Resolved: 06/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Given this DSLD:

contribute(enclosingCall(hasArgument(type()))) {
	property name:'foo'
}

And this snippet:

String flart(val, closure) { }

flart '', { 
	foo
}

foo should be resolved, but it's not.



 Comments   
Comment by Andrew Eisenberg [ 06/Jul/12 ]

Fixed with regression test.
https://github.com/groovy/groovy-eclipse/commit/3f69eb5954e72d29e545f2ef8acf0ecf1693b1e7





[GRECLIPSE-1458] DSLDs are not picked up from dependent projects Created: 06/Jul/12  Updated: 06/Jul/12  Resolved: 06/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If project A exports a DSLD in an output folder, and project B has project A on its classpath, the DSLD should be available in project B, but it is not.



 Comments   
Comment by Andrew Eisenberg [ 06/Jul/12 ]

The problem is that when we trawl through the classpath of a project looking for DSLDs to add to the classpath, we are only looking at binary entries. We need to look at source entries and also ignore source entries that are coming from the same project.

Comment by Andrew Eisenberg [ 06/Jul/12 ]

Fixed with regression tests.

https://github.com/groovy/groovy-eclipse/commit/e201391db0191512f6c9012aef1402f5892e60bd





[GRECLIPSE-1456] Add ResourceGroovyMethods to list of default categories Created: 05/Jul/12  Updated: 09/Jul/12  Resolved: 09/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Inferencing Engine
Affects Version/s: None
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

ResourceGroovyMethods is a new default category class introduced in Groovy 2.0. This should be added to our list of default categories used for inferencing.



 Comments   
Comment by Mauro Zallocco [ 08/Jul/12 ]

Without this, here is what the following code looks like in the debugger:

File f = new File("fred")
String s = f.getText()
f.eachLine {}
s.eachLine {}

Also going to Windows>Preferences>Java>Editor>Syntax Coloring
and unchecking Java>Deprecated members strikethrough
does not stop the strikethrough.
Perhaps this is another issue.

Comment by Andrew Eisenberg [ 09/Jul/12 ]

This is annoying.

I'll get a fix for this soon.

Comment by Andrew Eisenberg [ 09/Jul/12 ]

Fix committed with regression tests. See https://github.com/groovy/groovy-eclipse/commit/26b37d0ca79f4790188060ae30cbaf10c69488eb

Will be available in next snapshot build.





[GRECLIPSE-1455] Problem with @CompileStatic annotation in enum Created: 04/Jul/12  Updated: 11/Oct/12  Resolved: 05/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Editor
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Andrey Bloschetsov Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy/Grails Tool Suite Version: 3.0.0.M2 Build Id: 201206120636
Groovy-Eclipse plugin Version: 2.7.0.xx-20120703-1400-e42-RELEASE
OracleJDK 1.7.0_05 (64-Bit)
Ubuntu 12.04 (64-bit)


Number of attachments : 0

 Description   

@CompileStatic annotation in enum declaration break compilation.

Internal compiler error: java.lang.NullPointerException

Errors occurred during the build.
Errors running builder 'Java Builder' on project 'my-test-project'.
java.lang.NullPointerException

The problematic code is here:

@CompileStatic
enum Direction {

	UP,

	DOWN
}


 Comments   
Comment by Andrew Eisenberg [ 04/Jul/12 ]

A couple of us have tried to reproduce this problem, but can't. Can you attach the full stack trace from Window -> Show view -> Other.. -> Error log?

Also, I wonder if there are other projects in the workspace that are causing this. Can you also try creating a new workspace and place just a single project with this file in it?

Comment by Andrey Bloschetsov [ 04/Jul/12 ]

Stacktrace:

!ENTRY org.codehaus.groovy.eclipse.core 4 0 2012-07-04 18:21:58.210
!MESSAGE Exception when creating groovy completion proposal
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: null argument:
	at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
	at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
	at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.<init>(LazyJavaCompletionProposal.java:117)
	at org.eclipse.jdt.internal.ui.text.java.JavaMethodCompletionProposal.<init>(JavaMethodCompletionProposal.java:50)
	at org.codehaus.groovy.eclipse.codeassist.completions.GroovyJavaMethodCompletionProposal.<init>(GroovyJavaMethodCompletionProposal.java:50)
	at org.codehaus.groovy.eclipse.codeassist.completions.GroovyJavaMethodCompletionProposal.<init>(GroovyJavaMethodCompletionProposal.java:63)
	at org.codehaus.groovy.eclipse.codeassist.proposals.GroovyMethodProposal.createJavaProposal(GroovyMethodProposal.java:137)
	at org.codehaus.groovy.eclipse.codeassist.processors.StatementAndExpressionCompletionProcessor.generateProposals(StatementAndExpressionCompletionProcessor.java:442)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.computeCompletionProposals(GroovyCompletionProposalComputer.java:161)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:333)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:563)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:498)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:492)
	at org.eclipse.jface.text.contentassist.ContentAssistant$2.run(ContentAssistant.java:378)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3529)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3182)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
Comment by Andrew Eisenberg [ 04/Jul/12 ]

Thanks for the stack trace. This trace is coming from content assist. I tried invoking content assist in the file that you sent me, but this error didn't appear. Do you know when you got this exception?

Comment by Andrey Bloschetsov [ 04/Jul/12 ]

I'm trying to reproduce this bug in my environment, but she doesn't repeat anymore. I do not know what happened.
Yesterday I install some updates for my IDE, maybe this reason?

If the bug repeat again, I will try to gather more information.

Comment by Andrew Eisenberg [ 05/Jul/12 ]

No problem. Thanks for reporting. With the 2.7.0 final release, we did fix some CompileStatic problems. Perhaps you were using an earlier version when you reported and this got fixed with the final release.

Feel free to comment here or raise a new bug if you see this again.





[GRECLIPSE-1454] no Eclipse compile error for @Override on methods with signatures that don't match that of the parent class Created: 04/Jul/12  Updated: 04/Jul/12  Resolved: 04/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Thomas Weissinger Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac Snow Leopard


Issue Links:
Related
is related to GRECLIPSE-1428 Groovy editor does not respect @Override Open
is related to GROOVY-5413 groovyc should emit errors when @Over... Closed
is related to GROOVY-5011 @Override should be allowed (and veri... Open
Number of attachments : 0

 Description   

Tried searching for a similar bug, but couldn't find it.

Create a class like this:

class Foo {
	public static void main(String [] args) {
		Foo foo = new Foo();
		foo.callFoo();
	}
	
	void callFoo() {
		foo();
		FooSubclass subclass = new FooSubclass();
		subclass.foo();
	}
	
	void foo() {
		println "In foo"
	}
}

Create a subclass like this

class FooSubclass extends Foo {
	
	@Override
	void foo(String bar) {
		println "In foo subclass"
	}
}

There is no error in Eclipse about the fact that foo()'s signature is not the same. In fact, if you run Foo, it even executes fine (how?).

Now run a Maven build and you get an error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project perftest: Compilation failure
[ERROR] /Users/tweissin/git-source/foo/bar/target/generated-sources/groovy-stubs/main/com/trw/FooSubclass.java:[18,0] method does not override or implement a method from a supertype


 Comments   
Comment by Thomas Weissinger [ 04/Jul/12 ]

One minor thing, FooSubclass should extend Foo, so change the original FooSubclass to:

class FooSubclass extends Foo {

@Override
void foo(String bar)

{ println "In foo subclass" }

}

Comment by Andrew Eisenberg [ 04/Jul/12 ]

Updated your description and reformatted.

Comment by Andrew Eisenberg [ 04/Jul/12 ]

Thanks for reporting, but this is a duplicate of GRECLIPSE-1428. It is a little subtle what is going on here. The Groovy compiler itself is not catching the errant @Override annotation. Rather, the stub generator generates Java stubs and sends them to javac. It is javac that catches the error.

You can see that if you compile the two classes in this report with groovyc, then you don't get any error.

There are already a few bugs raised on the Groovy project for this: GROOVY-5413 and GROOVY-5011





[GRECLIPSE-1453] Groovy 2.0 support for final release Created: 28/Jun/12  Updated: 04/Jul/12  Resolved: 04/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Now that Groovy 2.0 is released, we need to incorporate this version into Groovy-Eclipse.



 Comments   
Comment by Andrew Eisenberg [ 04/Jul/12 ]

done





[GRECLIPSE-1452] Save Failed with AssertionFailedException destroying the buffer's content : changes since last save lost Created: 26/Jun/12  Updated: 10/Jan/13  Resolved: 31/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Critical
Reporter: Marc Paquette Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version: 2.7.0.xx-20120516-1600-e37-RELEASE


Attachments: HTML File sans titre     HTML File sans titre 10     HTML File sans titre 11     HTML File sans titre 12     HTML File sans titre 13     HTML File sans titre 2     HTML File sans titre 3     HTML File sans titre 4     HTML File sans titre 5     HTML File sans titre 6     HTML File sans titre 7     HTML File sans titre 8     HTML File sans titre 9    
Issue Links:
Related
relates to GRECLIPSE-1433 Intermittent editor error when editin... Resolved
relates to GRECLIPSE-1468 NPE thrown on new Groovy class wizard... Resolved
dependent
depends upon GRECLIPSE-1519 Intermittent hang when entering/editi... Resolved
Number of attachments : 13

 Description   

Once in a while, the current buffer is corrupted and its content is lost while editing a groovy file.

In retrospect, when this happens, it begins with a save operation that fails "silently" but buffer is left dirty (similar to GRECLIPSE-1423 ?) I'm usually late in noticing this and a subsequent save fails and the content is gone ! The physical file is still there and contains the last content succesfully saved (i.e. the file is not destroyed, just the in-memory buffer).

I will add event details reported by eclipse.



 Comments   
Comment by Marc Paquette [ 26/Jun/12 ]

Files attached contain the eclipse "Event Details" available via the Error Log view that are reported around the moment when the save fails.

Files are numered chronologically from "sans titre" (oldest) to "sans titre 13" (earliest).

Save failure occurs in sans titre 7 but relevant stack trace is reported in the warning in sans titre 8.

Comment by Andrew Eisenberg [ 27/Jun/12 ]

Thanks for reporting. Looks very similar to GRECLIPSE-1433. This has been something very hard for me to reproduce since none of the frames of the stack trace are from Groovy-Eclipse.

Do you have a reliable way to reproduce the problem?

Comment by Andrew Eisenberg [ 27/Jun/12 ]

Found this http://sourceforge.net/tracker/?func=detail&aid=3392346&group_id=80344&atid=559494 and this http://sourceforge.net/projects/eclipse-cs/forums/forum/274377/topic/4708915

My guess is that this is the same problem. Perhaps Groovy-Eclipse is grabbing the file buffer, but not releasing it. Still not sure where to look and why this just started happening.

Comment by Andrew Eisenberg [ 27/Jun/12 ]

I haven't been able to locate the problem yet, but it would help if you could tell me what version you last updated from. This would at least let me know that the problem occurred between then and the 2.7.0.xx-20120516-1600 build.

Comment by Andrew Eisenberg [ 27/Jun/12 ]

Are you using any code cleanups on save? Which ones?

Comment by Marc Paquette [ 27/Jun/12 ]

Hello Andrew,

Unfortunately, I don't know for sure when this started, but I remember seing it with the latest official release of the plugin before 2.7.0.xx-20120516-1600, and probably one before that also. I'll dig into my configuration history to see if I can at least give you a list of version I went through.

What I know is that it doesn't happen when I edit java files, only groovy. I use the same eclipse with the same pluging installed, only different workspaces.

I have no groovy Save Actions defined but I do have the following java save actions :

  • Format source code
    • Format all lines
  • Organize imports

Also, I have the Emacs+ keybindings ( Emacs+, 3.6.5, com.mulgasoft.emacsplus.feature.feature.group, MulgaSoft ) if that matters.

Comment by Marc Paquette [ 27/Jun/12 ]

Here is my installation history.

I started with

Groovy-Eclipse Feature 2.5.1.xx-20110628-1600-e37

in indigo, but I wasn't doing much groovy development at that time and I dont recall having corruption like this.

Next I went with

Groovy-Eclipse Feature 2.6.0.xx-20111212-0900-e37-RELEASE

in december 2011 and

Groovy-Eclipse Feature 2.6.1.xx-20120301-1000-e37-RELEASE

in march 2012. It is highly possible that I started to see save failures at that point : I remember that I started some more groovy development then.

After that, I installed

Groovy-Eclipse Feature 2.7.0.xx-20120418-1400-e37-RELEASE

in april, then

Groovy-Eclipse Feature 2.7.0.xx-20120516-1600-e37-RELEASE

in may.

Comment by Marc Paquette [ 27/Jun/12 ]

Would it help if I ran eclipse with the greclipse plugin built from sources ? Maybe I could put a breakpoint where the assertion fails in order to get to see what is happening ? I've never done that, but I guess it should be possible to run eclipse controlled by a debugging session from another copy of eclipse ?

Comment by Andrew Eisenberg [ 27/Jun/12 ]

Marc,

First, thanks for letting me know your version history, the linked bug report also mentions 2.6.1 as a possible start. This narrows things down.

And that would be incredibly helpful to run Eclipse in debug mode. It's called using a runtime workbench (launching Eclipse from inside Eclipse).

You need to make sure that you have the Eclipse PDE tools (plugin development environment, which you may already have installed) as well as the SDK (Eclipse sources) installed. And possibly, you'd want the Groovy-Eclipse SDK as well.

Once you have all of this, you need to set the appropriate breakpoint, but in order to do that, you need to import the appropriate project into your workspace.

  1. Start with an empty workspace
  2. File -> Import... -> Plugins and Fragments -> Next (just the default) -> And in the selection page, choose org.eclipse.jface.text
  3. Open AnnotationModel.java and set a breakpoint at line 742
  4. Now, you can launch a workbench in debug mode
  5. Go to your debug configurations page
  6. Dbl-click on Eclipse Application
  7. In the new launch configuration, choose your original workspace
  8. In the arguments tab, you may need to augment the VMargs to something like this: -Xmx1024M -XX:PermSize=64M -XX:MaxPermSize=128M
  9. Click debug

I wish it were easier to get started, but it would be extremely helpful if you wanted to step through this.

Comment by Andrew Eisenberg [ 29/Jun/12 ]

I added a few small changes, which I don't think will help (but may) and I also added some extra logging. Every once in a while check your error log for a message like:

GRECLIPSE-1452: Problem found in file. <path-name>

This means that a file buffer was closed when it shouldn't be. Paste the full stack trace here. If you still see the problem, but not the error message, then I need to think some more.

Hopefully, the next build will go through, and you can use the dev update site to install it. I don't know what the timestamp will be. I'll post a message when I find out.

Comment by Marc Paquette [ 29/Jun/12 ]

Alright, I will update with it once it gets built.
Meanwhile, I followed your instructions with success and I am now editing in an eclipse being debugged by another eclipse ! Could never figured all of this by myself, thanks again for the instructions.

Comment by Andrew Eisenberg [ 29/Jun/12 ]

Nice work!

Anyway, hold off on updating for now. We are just in the middle of our 2.0 work and the build is not succeeding yet.

Comment by Andrew Eisenberg [ 29/Jun/12 ]

OK. Available now from the E37 dev update site. See this commit for the changes:
https://github.com/groovy/groovy-eclipse/commit/5fc04e1bfc82006731c8d52fc8101fce1fdb3e13

Comment by Marc Paquette [ 03/Jul/12 ]

Just a quick note : I've been using the 2012-06-29 update this weekend for some moderate griffon hacking and I didn't see the problem and I haven't had any GRECLIPSE-1452 logs reported in the error log. That was with my "normal" eclipse, not in the runtime workbench.

I'm tempted to try putting my runtime workbench back to 2.6.1.xx-20120301-1000-e37-RELEASE and see if I hit the problem...

Comment by Andrew Eisenberg [ 04/Jul/12 ]

That sounds promising. I put the changes in to the final release of 2.7.0. Please let me know if you do try the earlier release. There's not much I can do on my side any more since I haven't been able to reproduce the problem.

Comment by Andrew Eisenberg [ 27/Jul/12 ]

There is a fix for GRECLIPSE-1468 available in a snapshot. Can you try this out? It may also fix this problem..

Comment by Andrew Eisenberg [ 08/Aug/12 ]

Any update here? I think the fix for GRECLIPSE-1468 will also fix the problem in this issue. Can you verify?

Comment by Marc Paquette [ 08/Aug/12 ]

Just got back from vacations I'll try the fix you mentionned and let you know.

Comment by Andrew Eisenberg [ 31/Aug/12 ]

Any update on this? I'm hoping to close this bug off if you are not seeing the problem any more.

Comment by Marc Paquette [ 31/Aug/12 ]

With 2.7.0.xx-20120703-1400-e37-RELEASE, it was already better, but I had once a buffer cleared with an assertion failed.

I upgraded to 2.7.1.xx-20120824-0800-e37 and haven't seen it since. So I guess this can be closed.

I have other problems related to saving, but I will open a new issue for this and update this one with its number.

Comment by Andrew Eisenberg [ 31/Aug/12 ]

Thanks for responding. Resolving.

Comment by Marc Paquette [ 31/Aug/12 ]

I created GRECLIPSE-1487 for the other problems I now see with groovy files in eclipse.

Comment by Francisco González [ 19/Nov/12 ]

I've reproduced the issue with version 2.7.1

Groovy-Eclipse plugin
Version: 2.7.1.xx-20120921-2000-e42RELEASE
Groovy version: org.codehaus.groovy

!ENTRY org.eclipse.ui 4 4 2012-11-19 12:00:33.055
!MESSAGE Save Failed

!ENTRY org.eclipse.ui 2 0 2012-11-19 12:00:33.065
!MESSAGE Save Failed
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
	at org.eclipse.ui.texteditor.AbstractMarkerAnnotationModel.updateMarkers(AbstractMarkerAnnotationModel.java:550)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.commitWorkingCopy(CompilationUnitDocumentProvider.java:1401)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$4.execute(CompilationUnitDocumentProvider.java:1449)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider$DocumentProviderOperation.run(TextFileDocumentProvider.java:132)
	at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
	at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
	at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
	at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:456)
	at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument(TextFileDocumentProvider.java:772)
	at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5066)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSave(CompilationUnitEditor.java:1247)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:1301)
	at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7198)
	at org.eclipse.ui.Saveable.doSave(Saveable.java:214)
	at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:346)
	at org.eclipse.ui.internal.SaveableHelper$3.run(SaveableHelper.java:193)
	at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:274)
	at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
	at org.eclipse.ui.internal.WorkbenchWindow$13.run(WorkbenchWindow.java:1675)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1672)
	at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:282)
	at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:261)
	at org.eclipse.ui.internal.SaveableHelper.saveModels(SaveableHelper.java:204)
	at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:144)
	at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.doSave(CompatibilityPart.java:404)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:235)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:199)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:89)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.savePart(PartServiceImpl.java:1179)
	at org.eclipse.ui.internal.WorkbenchPage.saveSaveable(WorkbenchPage.java:3469)
	at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3487)
	at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:76)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
	at sun.reflect.GeneratedMethodAccessor62.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
	at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1521)
	at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640)
	at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4528)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4976)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1029)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:923)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

Comment by Andrew Eisenberg [ 19/Nov/12 ]

Are you using any inner classes? The problem may be related to that. If so, try pulling out your inner classes into top-level.

Comment by Francisco González [ 21/Nov/12 ]

Yes. The file triggering the bug has an anonymous inner class.

Comment by Edward Staub [ 09/Jan/13 ]

I was seeing this also today.
I also was using a (static) inner class - not anonymous, in my case.
When I pulled it out (several hours ago), it stopped.
Version 2.7.1.xx-20120921-2000-e42RELEASE.

Should another issue be started on this?

Comment by Andrew Eisenberg [ 10/Jan/13 ]

It is likely the same issue.

Comment by Edward Staub [ 10/Jan/13 ]

Andrew, I'm confused because this issue is marked resolved and fixed in 2.7.1. It seems like either it wasn't resolved, or there really are two issues, one resolved and one not.

Comment by Andrew Eisenberg [ 10/Jan/13 ]

Sorry for not being more clear on this. The issue GRECLIPSE-1519 covers your problem.





[GRECLIPSE-1449] Exception thrown when removing type from active editor Created: 24/Jun/12  Updated: 31/Aug/12  Resolved: 31/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File SEC-1449-CreateMessagesTests.logs    
Number of attachments : 1

 Description   

While diagnosing GRECLIPSE-1448, I see this exception when deleting a class from an open editor:

Java Model Exception: Java Model Status [B [in [Working copy] Groovy.groovy [in <default> [in src [in Here]]]] does not exist]
	at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:495)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:536)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
	at org.eclipse.jdt.internal.core.Member.getCategories(Member.java:129)
	at org.eclipse.jdt.internal.ui.actions.CategoryFilterActionGroup$CategoryFilter.select(CategoryFilterActionGroup.java:81)
	at org.eclipse.jface.viewers.ViewerFilter.filter(ViewerFilter.java:51)
	at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:921)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:620)
	at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2645)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1923)
	at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:721)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1898)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1855)
	at org.eclipse.jface.viewers.StructuredViewer$8.run(StructuredViewer.java:1535)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1443)
	at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:403)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1404)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1533)
	at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:548)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1490)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaOutlinePage$JavaOutlineViewer.reconcile(JavaOutlinePage.java:396)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaOutlinePage$ElementChangedListener$1.run(JavaOutlinePage.java:185)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)


 Comments   
Comment by Robert Winch [ 12/Jul/12 ]

I got a very similar error and thought I would share the details in the event that it helps with this issue. I had the Groovy class CreateMessagesTest in two different packages initially. I then renamed the CreateMessagesTest to MockMvcCreateMessagesTest and changed its parent class to CreateMessagesTest. I then tried to import CreateMessagesTest using the SHIFT+CTRL+O (or SHIFT+CTRL+M I'm not sure which as my fingers tend to have a mind of their own). This produced the error below in my Eclipse logs. There seemed to be other errors immediately after that may or may not be related. I went ahead and attached those to the JIRA. I hope this helps in some manner. Please let me know if you think this is a separate issue and I can log a new one if you like.

!ENTRY org.eclipse.jdt.core 4 4 2012-07-12 13:42:00.893
!MESSAGE Error finding all types of CreateMessagesTest.groovy
!STACK 1
Java Model Exception: Java Model Status [CreateMessagesTest.groovy [in org.springframework.sample.test.htmlunit.e2etests [in src/test/groovy [in spring-test-mvc-htmlunit-showcase]]] does not exist]
	at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:505)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:246)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
	at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:196)
	at org.eclipse.jdt.internal.core.JavaElement.getChildrenOfType(JavaElement.java:210)
	at org.eclipse.jdt.internal.core.CompilationUnit.getTypes(CompilationUnit.java:933)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.findPrimaryType(GroovyCompilationUnit.java:520)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.getFullNameFromElement(JavaReflectionSynchronizer.java:210)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processJavaElementChanged(JavaReflectionSynchronizer.java:107)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processDelta(JavaModelListener.java:125)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processDelta(JavaReflectionSynchronizer.java:343)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processChildren(JavaModelListener.java:78)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processChildren(JavaReflectionSynchronizer.java:336)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processJavaElementChanged(JavaModelListener.java:204)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processJavaElementChanged(JavaReflectionSynchronizer.java:179)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processDelta(JavaModelListener.java:122)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processDelta(JavaReflectionSynchronizer.java:343)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processChildren(JavaModelListener.java:78)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processChildren(JavaReflectionSynchronizer.java:336)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processJavaElementChanged(JavaModelListener.java:218)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processJavaElementChanged(JavaReflectionSynchronizer.java:159)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processDelta(JavaModelListener.java:119)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processDelta(JavaReflectionSynchronizer.java:343)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processChildren(JavaModelListener.java:78)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processChildren(JavaReflectionSynchronizer.java:336)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processJavaElementChanged(JavaReflectionSynchronizer.java:128)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processDelta(JavaModelListener.java:116)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processDelta(JavaReflectionSynchronizer.java:343)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processChildren(JavaModelListener.java:78)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processChildren(JavaReflectionSynchronizer.java:336)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processJavaElementChanged(JavaModelListener.java:176)
	at org.eclipse.jem.workbench.utility.JavaModelListener.processDelta(JavaModelListener.java:113)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.processDelta(JavaReflectionSynchronizer.java:343)
	at org.eclipse.jem.workbench.utility.JavaModelListener.elementChanged(JavaModelListener.java:63)
	at org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer.elementChanged(JavaReflectionSynchronizer.java:265)
	at org.eclipse.jdt.internal.core.DeltaProcessor$4.run(DeltaProcessor.java:1682)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.core.DeltaProcessor.notifyListeners(DeltaProcessor.java:1672)
	at org.eclipse.jdt.internal.core.DeltaProcessor.firePostChangeDelta(DeltaProcessor.java:1506)
	at org.eclipse.jdt.internal.core.DeltaProcessor.fire(DeltaProcessor.java:1482)
	at org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:2094)
	at org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:470)
	at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
	at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
	at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395)
	at org.eclipse.core.internal.resources.Workspace.checkpoint(Workspace.java:557)
	at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:263)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306)
	at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92)
	at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:218)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
!SUBENTRY 1 org.eclipse.jdt.core 4 969 2012-07-12 13:42:00.894
!MESSAGE CreateMessagesTest.groovy [in org.springframework.sample.test.htmlunit.e2etests [in src/test/groovy [in spring-test-mvc-htmlunit-showcase]]] does not exist
Comment by Andrew Eisenberg [ 12/Jul/12 ]

Where does org.eclipse.jem come from? Did you install this separately? It looks like there is a refactoring participant coming from org.eclipse.jem and calling into an outdated GroovyCompilationUnit. It might be related...not sure.

Comment by Robert Winch [ 12/Jul/12 ]

Unfortunately I know very little about Eclipse internals so I am not certain where it came from. I believe all the extensions I installed all came from the STS dashboard (except one):

  • Gradle Support
  • Groovy 2.0 Compiler
  • Groovy Eclipse
  • Subversive
  • EclEmma
  • FindBugs
  • PMD
  • AnyEdit

It appears the plugin may be originating from WTP. You can see that the linked source includes JavaReflectionSynchronizer which is present in my stack.

Does this provide any value? Let me know if there is anything else I can do to assist.

PS: Is this a separate issue (sounds like you suspect it may not be a GRECLIPSE issue)? If so, I can move to its own JIRA, or we can leave it here if you prefer, or...

Comment by Andrew Eisenberg [ 31/Aug/12 ]

Finally got a chance to look at this bug. The original stack trace is thrown (indirectly) by the GroovyOutlinePage. The groovy outline page does not support categories and when the top level type is deleted, this causes an error.

@RobWinch, I think the exception that you are seeing is coming from a different place. Most likely it is being indirectly caused through one of the plugins you have installed. If you see this exception reproducibly, then I will look into it more.

Comment by Robert Winch [ 31/Aug/12 ]

FYI...I haven't seen this error in a long time. You can probably resolve it and if it comes up again I can open a new issue or comment on this one.

Comment by Andrew Eisenberg [ 31/Aug/12 ]

Yes, please open a new issue if you see it again.





[GRECLIPSE-1448] NPE in GenericsMapper when more than 2 levels of inheritance with generics Created: 24/Jun/12  Updated: 28/Jun/12  Resolved: 28/Jun/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Content Assist
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Tomasz Wysocki Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.9.2 Windows x64


Number of attachments : 0

 Description   
Unable to find source-code formatter for language: groovy. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
class A extends B<String> {
  // Ctrl + Space here	
}

class B<T> extends C<T> {
}

class C<T> {
   T t
}

Invoking of content assist in class A results in NPE being thrown.

Checked also on version from master 4c73473b53da491e7037c4e8fc5009cdf86139b5 (stacktrace below from that version)

!ENTRY org.eclipse.jdt.ui 2 0 2012-06-24 21:49:10.206
!MESSAGE The 'Groovy Code Completions' proposal computer from the 'org.codehaus.groovy.eclipse.codeassist.completion' plug-in did not complete normally. The extension has thrown a runtime exception.
!STACK 0
java.lang.NullPointerException
	at org.eclipse.jdt.groovy.search.GenericsMapper.gatherGenerics(GenericsMapper.java:34)
	at org.codehaus.groovy.eclipse.codeassist.processors.NewMethodCompletionProcessor.getParameterTypeNames(NewMethodCompletionProcessor.java:191)
	at org.codehaus.groovy.eclipse.codeassist.processors.NewMethodCompletionProcessor.createProposal(NewMethodCompletionProcessor.java:147)
	at org.codehaus.groovy.eclipse.codeassist.processors.NewMethodCompletionProcessor.generateProposals(NewMethodCompletionProcessor.java:90)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.computeCompletionProposals(GroovyCompletionProposalComputer.java:161)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:318)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:267)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:283)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:243)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1830)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:488)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482)
	at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1656)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:183)
	at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185)
	at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
	at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
	at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1509)
	at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640)
	at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4528)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2531)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)

It seems that during superclass recursive traversal in NewMethodCompletionProcessor#findResolvedType the superclass of class B is not class C but java.lang.Object!



 Comments   
Comment by Tomasz Wysocki [ 24/Jun/12 ]

Protecting GenericsMapper:34 from null resolved type (by returning null mapper) seems to hide the issue and allows to use content assist normally

Comment by Andrew Eisenberg [ 24/Jun/12 ]

Thanks for reporting and the potential fix. I'll have a look.

Comment by Andrew Eisenberg [ 24/Jun/12 ]

I can reproduce the problem using the test case you provided. There is something more sinister going on here. In NewMethodCompletionProcessor.getParameterTypeNames, the unresolved super type of B is being returned as Object, when it should be returned as {{ C<T> }}.

Even when I add the null check in GenericsMapper as you suggest, selecting to override a method that uses generics (eg- the implicit setter setT, will cause some exceptions and an invalid proposal. Doing so could be a stop-gap solution until we fix the underlying problem, but I'd prefer to investigate more why this is happening.

Comment by Andrew Eisenberg [ 24/Jun/12 ]

I checked the AST in the groovyConsole and compiling the script on the command line produces a correct unresolved suepr class for B.

Comment by Andrew Eisenberg [ 28/Jun/12 ]

Fixed. Looks like the NewMethodCompletionProcessor was traversing up the wrong branch of the redirect/resolved supertype hierarchy.

Commit is here: https://github.com/groovy/groovy-eclipse/commit/0228f3b10595ac01e10492e6172c624b781cfdd2

Turns out to be a small fix.





[GRECLIPSE-1447] @CompileStatic problem with annotation Created: 22/Jun/12  Updated: 11/Oct/12  Resolved: 29/Jun/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

An exception is being thrown in the editor. Looks like it is related to compile static.

Groovy/Grails Tool Suite Version: 3.0.0.M2 Build Id: 201206120636;
Groovy-Eclipse plugin Version: 2.6.1.xx-20120620-1100-e42-RELEASE;
OracleJDK 1.7.0_04-b20 (64-Bit)
Ubuntu 12.04 (64-bit)


General error during instruction selection: Problem in
JDTAnnotatioNode.createExpressionFor(binding=I (id=10) value=(int)1)

org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug:
Problem in JDTAnnotatioNode.createExpressionFor(binding=I (id=10)
value=(int)1)
       at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.createExpressionFor(JDTAnnotationNode.java:173)
       at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.ensureMembersInitialized(JDTAnnotationNode.java:141)
       at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.getMember(JDTAnnotationNode.java:65)
       at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.pickInferredTypeFromMethodAnnotation(StaticTypeCheckingVisitor.java:1313)
       at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:1518)
       at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:196)
       at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:67)
       at org.codehaus.groovy.ast.CodeVisitorSupport.visitReturnStatement(CodeVisitorSupport.java:73)
       at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitReturnStatement(ClassCodeVisitorSupport.java:224)
       at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitReturnStatement(StaticTypeCheckingVisitor.java:1012)
       at org.codehaus.groovy.ast.stmt.ReturnStatement.visit(ReturnStatement.java:47)
       at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
       at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
       at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
       at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
       at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
       at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1003)
       at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
       at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:1184)
       at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(StaticCompilationVisitor.java:108)
       at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1169)
       at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
       at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:206)
       at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:99)
       at org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:57)
       at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:169)
       at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:242)
       at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1190)
       at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:622)
       at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:600)
       at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:577)
       at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
       at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1534)
       at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
       at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
       at java.lang.Thread.run(Thread.java:722)

The problematic code is here:

@CompileStatic
@EqualsAndHashCode(useCanEqual = false, includes = 'id')
class BeanDbo {

       String id

       // more fields
}


 Comments   
Comment by Andy Clement [ 29/Jun/12 ]

Fixed. couldn't recreate it with that testcase but it also happens in the grails 2.2 build.





[GRECLIPSE-1445] Compile java source and groovy source in same output folder Created: 20/Jun/12  Updated: 26/Jun/12  Resolved: 22/Jun/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution, Compiler Integration
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Fabrice Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

groovy plugin
MyEclipse


Number of attachments : 0

 Description   

Hi,

I'm using groovy plugin and MyEclipse. I have a problem when I compile java source and groovy source (command: Project -> Clean) in the same output folder. There is a conflict between .class from java source and .class from groovy source. I have only the .class from groovy source in my output folder.



 Comments   
Comment by Andrew Eisenberg [ 20/Jun/12 ]

I will need to know more information before I can help. Are there name conflicts between your java and groovy files? Are they coming from different source folders? Are there any errors in your error log (Window -> Show view -> Other -> Error log)?

Can you attach the project that is not working for you?

Comment by Fabrice [ 20/Jun/12 ]

Hi,

Are there name conflicts between your java and groovy files?
No, there aren't.

Are they coming from different source folders?
Yes. The structure of my project is the following :
src/main/java
src/main/groovy
src/main/resources

Are there any errors in your error log (Window -> Show view -> Other -> Error log)?
No, there are no errors in log.

I explain you in more details the problem. My output forder is src/main/webapp/WEB-INF/classes. And I want my .class files (from groovy and Java) in this folder when I execute the command Project -> clean. I precise the groovy and java files can be in the same package (But they are not the same classname).
But, I have only .class from Java file or .class from Groovy file in my output folder but not both. So my project doesn't work.

Comment by Andrew Eisenberg [ 20/Jun/12 ]

Is this a maven project?

If you can't share the entire project, then at least send over the .project, .classpath, and pom.xml (if it exists). Attach it here, or contact me directly via email if the files contain confidential information.

Comment by Fabrice [ 21/Jun/12 ]

OK. I send you in private the configuration of my project.

Comment by Andrew Eisenberg [ 21/Jun/12 ]

Thanks for the project. What version of groovy-eclipse are you using? It looks like your project is configured for pre-2.0 (from 2009 and earlier). Also, you are using an old version of m2eclipse.

In .project file, remove these lines:

		<nature>org.maven.ide.eclipse.maven2Nature</nature>
		<nature>org.codehaus.groovy.eclipse.groovyNature</nature>

replace with:

		<nature>org.eclipse.m2e.core.maven2Natur</nature>
		<nature>org.eclipse.jdt.groovy.core.groovyNature</nature>

Remove the groovy builder and the maven builder. Replace with just:

		<buildCommand>
			<name>org.eclipse.m2e.core.maven2Builder</name>
			<arguments>
			</arguments>
		</buildCommand>

In the .classpath, remove the following entries:

	<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>

replace with

	<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER"/>

And you should be good to go.

Of course, this assumes that you already have a modern m2e and a modern groovy-eclipse installed in your Eclipse.

Comment by Fabrice [ 22/Jun/12 ]

Hi,

Effectively, I'm using MyEclipse 8.5 (release in 2010). So the installed plugins are old.
The version of maven plugin is 0.10.0.20100209-0800.

I can't upgrade my IDE. Is there an other solution to resolve this?

Comment by Andrew Eisenberg [ 22/Jun/12 ]

You're probably fine with the old version of the maven plugin, but you need to upgrade your groovy-eclipse. Groovy-Eclipse pre-2.0 was not really usable for any large projects.

Comment by Andrew Eisenberg [ 22/Jun/12 ]

Unfortunately, not much I can do unless you upgrade.

Comment by Fabrice [ 26/Jun/12 ]

I upgraded groovy-eclipse in 2.1.0. And it works. The groovy/java code source is compiled in the same output directory (if the .classpath is correctly configured of course).

Thank you for your help!!
Regards,





[GRECLIPSE-1443] Rename refactor does not update Javadoc Created: 05/Jun/12  Updated: 05/May/14  Resolved: 24/Apr/14

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.9.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: help-requested, wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Users would expect that rename -> refactor would update Javadoc/Groovydoc, but it doesn't.



 Comments   
Comment by Vasiliy Kizhaev [ 23/Apr/14 ]

Fixing commit was merged to master: https://github.com/groovy/groovy-eclipse/pull/30





[GRECLIPSE-1442] delegatesTo doesn't recognize getters Created: 29/May/12  Updated: 05/Jun/12  Resolved: 05/Jun/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Vladimír Oraný Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux x64


Number of attachments : 0

 Description   

if I use delegatesTo type: MyCategory, asCategory: true and I have following method

static ReturnType getSomething(EnhancedType type){...}

and have a code meeting all conditions

ReturnType rt = ...

// this is recognized well
rt.getSomething()

// this is not recognized and is shown underlined
rt.something

the point is that when getter method is added to the type, the property should be added as well



 Comments   
Comment by Andrew Eisenberg [ 05/Jun/12 ]

I have a fix locally. Needs a few tests before committing. This works for non-category style delegatesTo, but I never included the implementation for category style.

Comment by Andrew Eisenberg [ 05/Jun/12 ]

Fixed. I pushed this sha to github: 0a05ebe71341df6a0dac459c4da769c8a1b4db6c





[GRECLIPSE-1441] Breaking change in plexus compiler api 2.9 Created: 29/May/12  Updated: 30/May/12  Resolved: 30/May/12

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to MCOMPILER-172 Breaking change to plexus compiler ap... Closed
is related to MVNCONFSITE-2 Breaking change to plexus compiler ap... Resolved
Number of attachments : 0

 Description   

From the mailing list:

Hi,

after using the newly released maven-compiler-plugin v.2.5 (which is indeed using plexus-compiler v.1.9) it seems, the api has changed which results

in an error:

maven-compiler-plugin:2.5:compile failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-compiler-plugin:2.5:compile: java.lang.NoSuchMethodError: org.codehaus.plexus.compiler.CompilerConfiguration.getCustomCompilerArguments()Ljava/util/LinkedHashMap;

This should be the Cause of the problem:

org.codehaus.plexus.compiler.CompilerConfiguration

v.1.8.1: java.util.LinkedHashMap getCustomCompilerArguments()
v.1.9.0: java.util.Map<String, String> getCustomCompilerArguments()

Im using

<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.6.0-01</version>
</dependency>

I'll get a new snapshot release out.



 Comments   
Comment by Andrew Eisenberg [ 30/May/12 ]

The plexus-compiler-api is now fixed. I tested a snapshot version of the fix and it works. I have a new integration test to ensure backwards and forwards compatibility.





[GRECLIPSE-1440] Refresh DSLD scripts error - java/util$Map Created: 29/May/12  Updated: 23/Jul/12  Resolved: 23/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: mike Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I receive the following error for a grails project in Spring Source Tool Suite:

An internal error occurred during: "Refresh DSLD scripts".
java/util$Map

Any help would be appreciated



 Comments   
Comment by Andrew Eisenberg [ 29/May/12 ]

Can you take a look at your error log and find the stack trace? Window -> Show view -> Other... -> Error log.

If you don't see the stack trace there, go to the groovy event console and look for it. Paste the stack trace into a comment on this issue.

Also, does this problem only happen for some files, or all of them? What version of Groovy-Eclipse and STS are you using?

ps- to get to the groovy event console, follow these instructions: http://groovy.codehaus.org/Groovy-Eclipse+2.1.2+New+and+Noteworthy#Groovy-Eclipse212NewandNoteworthy-TimersforASTTransformoperationsnowshowninGroovyEventConsole

Comment by Andrew Eisenberg [ 26/Jun/12 ]

Any update on this?

Comment by Andreas Gerstmayr [ 20/Jul/12 ]

Same here.
I'm using Groovy/Grails Tool Suite 3.0.0.M3 with Grails 2.1.0 and JDK 1.7.0_05 on 64 bit.
Happens when I import a project (project created with same IDE on another machine with different JDK Version).

java.lang.NoClassDefFoundError: java/util$Map
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
	at java.lang.Class.getDeclaredMethods(Class.java:1808)
	at org.codehaus.groovy.reflection.CachedClass$3$1.run(CachedClass.java:84)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.codehaus.groovy.reflection.CachedClass$3.initValue(CachedClass.java:81)
	at org.codehaus.groovy.reflection.CachedClass$3.initValue(CachedClass.java:79)
	at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
	at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
	at org.codehaus.groovy.reflection.CachedClass.getMethods(CachedClass.java:250)
	at groovy.lang.MetaClassImpl.populateMethods(MetaClassImpl.java:334)
	at groovy.lang.MetaClassImpl.fillMethodIndex(MetaClassImpl.java:284)
	at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2904)
	at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
	at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:227)
	at org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.java:751)
	at groovy.lang.GroovyObjectSupport.<init>(GroovyObjectSupport.java:32)
	at groovy.lang.Script.<init>(Script.java:40)
	at groovy.lang.Script.<init>(Script.java:37)
	at com.foo.grails.<init>(grails.dsld)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
	at java.lang.Class.newInstance0(Class.java:372)
	at java.lang.Class.newInstance(Class.java:325)
	at org.codehaus.groovy.eclipse.dsl.script.DSLDScriptExecutor.executeScript(DSLDScriptExecutor.java:254)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.refreshProject(RefreshDSLDJob.java:336)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:268)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassNotFoundException: java.util$Map
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
	at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:696)
	at groovy.lang.GroovyClassLoader$InnerLoader.loadClass(GroovyClassLoader.java:449)
	at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:805)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	... 31 more

// edit: The problem was a missing .classpath file. Anyway, another error message would be helpful .

Comment by Andrew Eisenberg [ 23/Jul/12 ]

I would have expected that if there were a missing .classpath file, then there would have been many more errors on the project, or at least things would be behaving so weird that this exception wouldn't be the only problem that you see.

And...I tried removing the .classpath file on an existing grails project and I didn't see this same exception, but I did see other compile problems, such as this:

The project was not built since its build path is incomplete. Cannot find the class file for java.lang.Object. Fix the build path then try building this project

If this is a compile problem that you were seeing, then I am not overly concerned about the NoClassDefFoundError since fixing the former would fix the latter.

Comment by Andrew Eisenberg [ 23/Jul/12 ]

I am resolving this issue since I have a good enough understanding of what is going on now. If you still think that this issue is not adequately addressed by classpath and compile problems in the problems view, then feel free to add a comment.





[GRECLIPSE-1439] Make Grails Command Prompt respond to enter key on number-pad Created: 28/May/12  Updated: 28/May/12  Resolved: 28/May/12

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Trivial
Reporter: mike powers Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Number of attachments : 0

 Description   

When using the Grails Command Prompt popup-window to run a Grails command, hitting the enter key, next to the single-quote key, works as expected. If I hit the enter key grouped with the number-pad, to the right on my keyboard, nothing happens. I would expect the behavior to be the same, regardless of which enter key I hit on the keyboard. I have tried this in multiple versions of Linux (Ubunut + RHEL). One of my coworkers also independently discovered this (trivial) issue.



 Comments   
Comment by Andrew Eisenberg [ 28/May/12 ]

Thanks for raising this issue. This should have been raised in the STS issue tracker. I raised it for you. You can track the progress at the following link:
https://issuetracker.springsource.com/browse/STS-2656

Comment by mike powers [ 28/May/12 ]

Thanks Andrew!





[GRECLIPSE-1437] Error while building the java-groovy project in RAD 8 Created: 24/May/12  Updated: 24/May/12  Resolved: 24/May/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.7.0.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Critical
Reporter: Satya Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP3


Attachments: Zip Archive RADError.zip    
Issue Links:
Duplicate
duplicates GRECLIPSE-1352 Cannot complete the install because o... Resolved
Number of attachments : 1

 Description   

I have installed Groovy Eclipse plugin 2.7.0 on Rational Application Develper 8 (Based on Eclipse 3.6 Helios) on Windows XP. I have a project both groovy and java source files. I am trying to do a clean (Project->clean) then RAD 8 automatically starts building and throwing the following error

Errors occurred during the build.
Errors running builder 'Java Builder' on project ''.
org/codehaus/jdt/groovy/integration/LanguageSupportFactory

I have attached the screen shot of the error.
Could you please help me fixing it?



 Comments   
Comment by Andrew Eisenberg [ 24/May/12 ]

The problem is related to the fact that RAD uses a different version of JDT that is not covered by our JDT patch. See GRECLIPSE-1352.

Comment by Andrew Eisenberg [ 24/May/12 ]

As described in the link, it is possible to get this working, but there is not clean solution.

Comment by Andrew Eisenberg [ 24/May/12 ]

The interesting thing is that you were able to install groovy-eclipse whereas the linked issue describes a situation where the install could not happen.

If nothing in the linked issue helps, feel free to comment here and I'll have some other suggestions.





[GRECLIPSE-1434] Formatter produces different results depending on initial text Created: 27/Apr/12  Updated: 02/Oct/12  Resolved: 02/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In this snippet, perform format:

a = { 0 } as List

and the result is

a = {
	0 } as List

Now, perform format again and you go back to the first snippet. Each time a format occurs, the text changes.



 Comments   
Comment by Andrew Eisenberg [ 02/Oct/12 ]

Fixed.





[GRECLIPSE-1433] Intermittent editor error when editing a complex groovy file. Created: 27/Apr/12  Updated: 04/Feb/13  Resolved: 04/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Critical
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File error-log-greclipse-1433.log    
Issue Links:
Related
relates to GRECLIPSE-1468 NPE thrown on new Groovy class wizard... Resolved
is related to GRECLIPSE-1452 Save Failed with AssertionFailedExcep... Resolved
dependent
depends upon GRECLIPSE-1519 Intermittent hang when entering/editi... Resolved
Number of attachments : 1

 Description   

When editing a particular groovy file (editing, saving, selecting text), I get the following exceptions in the error log. The eclipse editor turns white, states "Error" and prevents saving the file.

Here are the exceptions it reports:

Error in inferencing engine for File.groovy

eclipse.buildId=M20120208-0800
java.version=1.7.0_03
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_CA
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os linux -ws gtk -arch x86 -product org.eclipse.epp.package.jee.product -clean

java.lang.ArrayIndexOutOfBoundsException: 27124
at org.codehaus.groovy.eclipse.editor.highlighting.SemanticHighlightingReferenceRequestor.isRealASTNode(SemanticHighlightingReferenceRequestor.java:129)
at org.codehaus.groovy.eclipse.editor.highlighting.SemanticHighlightingReferenceRequestor.acceptASTNode(SemanticHighlightingReferenceRequestor.java:73)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleRequestor(TypeInferencingVisitorWithRequestor.java:1952)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleSimpleExpression(TypeInferencingVisitorWithRequestor.java:1834)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstantExpression(TypeInferencingVisitorWithRequestor.java:1355)
at org.codehaus.groovy.ast.expr.ConstantExpression.visit(ConstantExpression.java:75)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1518)
at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1286)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstructorOrMethod(TypeInferencingVisitorWithRequestor.java:785)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:524)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:370)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:318)
at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:112)
at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

And the following:

eclipse.buildId=M20120208-0800
java.version=1.7.0_03
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_CA
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os linux -ws gtk -arch x86 -product org.eclipse.epp.package.jee.product -clean

Unhandled event loop exception

org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.core.runtime.AssertionFailedException: assertion failed: )
at org.eclipse.swt.SWT.error(SWT.java:4282)
at org.eclipse.swt.SWT.error(SWT.java:4197)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3563)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3212)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.jface.text.source.AnnotationModel.getRegionAnnotationIterator(AnnotationModel.java:742)
at org.eclipse.jface.text.source.AnnotationModel.getAnnotationIterator(AnnotationModel.java:700)
at org.eclipse.jface.text.source.AnnotationRulerColumn.doPaint1(AnnotationRulerColumn.java:727)
at org.eclipse.jface.text.source.AnnotationRulerColumn.doubleBufferPaint(AnnotationRulerColumn.java:541)
at org.eclipse.jface.text.source.AnnotationRulerColumn.redraw(AnnotationRulerColumn.java:824)
at org.eclipse.jface.text.source.AnnotationRulerColumn$6.run(AnnotationRulerColumn.java:807)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 22 more

For reasons of confidentiality I cannot post the source here.



 Comments   
Comment by Andrew Eisenberg [ 27/Apr/12 ]

I have an idea of what might be wrong. If you can email me the source file directly, I can take a look at it. Otherwise, I will have to make some guesses and put out a new version so you can try.

Comment by Andrew Eisenberg [ 27/Apr/12 ]

Thanks for the files, but unfortunately not able to reproduce the problem. I committed a potential fix and it should go through the build cycle in a couple of hours. When you get a chance, upgrade to the latest dev build and let me know if it fixes your problem. If not, we will have to try working through this in a different way.

Comment by Andrew Eisenberg [ 05/Jun/12 ]

Any updates on this?

Comment by Bob Tiernay [ 12/Jun/12 ]

This is still occurring in the latest development build 2.7.0.xx-20120611-1500-e37-RELEASE. This is very unfortunate since it occurs quite frequently for some users on our team and is having a large impact on productivity.

Comment by Andrew Eisenberg [ 12/Jun/12 ]

Thanks for the feedback. This issue contains two stack traces that are likely unrelated. The change I put in should address the first exception. Are you still seeing that one? If so, can you repaste the stack trace since line numbers should be different now.

As for the second exception:

  1. Does this happen only in a single file, or is it in multiple files?
  2. How reproducible is this problem?
  3. Can you try to trim down a file so that this happens in something that you can share?
Comment by Andrew Eisenberg [ 26/Jun/12 ]

Any updates on this?

Comment by Bob Tiernay [ 26/Jun/12 ]

Sorry for the delay Andrew.

The problem continues to occur. Since I'm not the one who encounters the issue, I don't have any additional information to give you. This only happens in a couple of groovy files we have. I believe it will be very difficult to debug since there are a number of feature interactions here: AST transformations, DSLD, m2e, nested closures, "as" expressions, etc. Because the error is so random, it is very difficult to narrow in on the problem, even after removing some of these features.

I can resend the file via email if you wish.

Bob

Comment by Andrew Eisenberg [ 27/Jun/12 ]

Looks like the same issue is being reported in GRECLIPSE-1452. Perhaps I can get some more information there.

Comment by Andrew Eisenberg [ 27/Jun/12 ]

As I mentioned in GRECLIPSE-1452, it looks like Groovy-Eclipse is releasing a document that it doesn't own (or doubly releasing a document). This disposes the annotation model and can cause the problem you are seeing.

Two questions:

  1. what version did you upgrade from before you started seeing this problem?
  2. Are you using code cleanups on save? Which ones?
Comment by Bob Tiernay [ 27/Jun/12 ]

1. I can't recall the first time this happened since it happened to me once and then the next time was much later. Then my coworker had this happening every hour or so on this one file
2. Just "Remove unnecessary semicolons". I will check my coworker's settings.

Comment by Andrew Eisenberg [ 29/Jun/12 ]

I added a few small changes, which I don't think will help (but may) and I also added some extra logging. Every once in a while check your error log for a message like:

GRECLIPSE-1452: Problem found in file. <path-name>

This means that a file buffer was closed when it shouldn't be. Paste the full stack trace here. If you still see the problem, but not the error message, then I need to think some more.

Hopefully, the next build will go through, and you can use the dev update site to install it. I don't know what the timestamp will be. I'll post a message when I find out.

Comment by Andrew Eisenberg [ 29/Jun/12 ]

Hold off on updating for now. We are in the middle of our 2.0 work and the build is not going through.

Comment by Andrew Eisenberg [ 29/Jun/12 ]

OK. Available now from the E37 dev update site. See this commit for the changes:
https://github.com/groovy/groovy-eclipse/commit/5fc04e1bfc82006731c8d52fc8101fce1fdb3e13

Comment by Andrew Eisenberg [ 27/Jul/12 ]

There is a fix for GRECLIPSE-1468 available in a snapshot. Can you try this out? It may also fix this problem..

Comment by Andrew Eisenberg [ 08/Aug/12 ]

Any update here?

Comment by Bob Tiernay [ 09/Aug/12 ]

No problems lately. Again, I'm not the one who has really been bit by this bug. Others on my team have upgraded to nightly snapshot so I guess no news is good news in this regard. I recommend closing this bug as fixed. I will be sure to comment if it comes up again.

Thanks for your help with this Andrew!

Comment by Andrew Eisenberg [ 09/Aug/12 ]

As requested...resolving. Please comment if you see the problem again.

Comment by Rick Mangi [ 07/Sep/12 ]

I'm getting this error on 2 different computers with Groovy Tool Suite installed. Also saw it with a Juno installation with the Groovy stuff from STS installed manually. I keep getting this stack trace:

Long stack trace, but it seems to all start with a code completion template error. The net result is that you can't save the file you're working on.

!ENTRY org.eclipse.jdt.ui 2 0 2012-09-07 14:08:16.017
!MESSAGE The 'Groovy Code Completions' proposal computer from the 'org.codehaus.groovy.eclipse.codeassist.completion' plug-in did not complete normally. The extension has thrown a runtime exception.
!STACK 0
java.lang.ArrayIndexOutOfBoundsException: 340
at org.codehaus.groovy.eclipse.codeassist.CharArraySourceBuffer.charAt(CharArraySourceBuffer.java:35)
at org.codehaus.groovy.eclipse.core.util.ExpressionFinder.findPreviousTypeNameToken(ExpressionFinder.java:243)
at org.codehaus.groovy.eclipse.codeassist.processors.NewFieldCompletionProcessor.findCompletionTypeName(NewFieldCompletionProcessor.java:175)
at org.codehaus.groovy.eclipse.codeassist.processors.NewFieldCompletionProcessor.generateProposals(NewFieldCompletionProcessor.java:143)
at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.computeCompletionProposals(GroovyCompletionProposalComputer.java:161)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:333)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1460)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1449)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:375)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

!ENTRY org.eclipse.ui 4 0 2012-09-07 14:08:16.133
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.jface.text.source.AnnotationModel.getRegionAnnotationIterator(AnnotationModel.java:742)
at org.eclipse.jface.text.source.AnnotationModel.getAnnotationIterator(AnnotationModel.java:700)
at org.eclipse.jface.text.source.AnnotationRulerColumn.doPaint1(AnnotationRulerColumn.java:727)
at org.eclipse.jface.text.source.AnnotationRulerColumn.doubleBufferPaint(AnnotationRulerColumn.java:541)
at org.eclipse.jface.text.source.AnnotationRulerColumn.access$3(AnnotationRulerColumn.java:517)
at org.eclipse.jface.text.source.AnnotationRulerColumn$1.paintControl(AnnotationRulerColumn.java:289)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:230)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4134)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
at org.eclipse.swt.widgets.Control.drawWidget(Control.java:1244)
at org.eclipse.swt.widgets.Canvas.drawWidget(Canvas.java:163)
at org.eclipse.swt.widgets.Widget.drawRect(Widget.java:741)
at org.eclipse.swt.widgets.Canvas.drawRect(Canvas.java:158)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5471)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(Display.java:4873)
at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5239)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.nextEventMatchingMask(NSApplication.java:94)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3613)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.jface.dialogs.MessageDialog.open(MessageDialog.java:334)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.informUser(CompletionProposalComputerRegistry.java:465)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:354)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1460)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1449)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:375)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

!ENTRY org.eclipse.ui 4 0 2012-09-07 14:08:16.135
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.jface.text.source.AnnotationModel.getRegionAnnotationIterator(AnnotationModel.java:742)
at org.eclipse.jface.text.source.AnnotationModel.getAnnotationIterator(AnnotationModel.java:700)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.getAnnotation(JavaEditor.java:3921)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.updateStatusLine(JavaEditor.java:3601)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.selectionChanged(JavaEditor.java:2295)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$EditorSelectionChangedListener.selectionChanged(JavaEditor.java:300)
at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2755)
at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2703)
at org.eclipse.jface.text.TextViewer$5.run(TextViewer.java:2682)
at org.eclipse.swt.widgets.Display.timerProc(Display.java:4697)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5455)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(Display.java:4873)
at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5239)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.nextEventMatchingMask(NSApplication.java:94)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3613)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.jface.dialogs.MessageDialog.open(MessageDialog.java:334)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.informUser(CompletionProposalComputerRegistry.java:465)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:354)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1460)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1449)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:375)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

!ENTRY org.eclipse.ui 4 0 2012-09-07 14:08:16.136
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException)
at org.eclipse.swt.SWT.error(SWT.java:4361)
at org.eclipse.swt.SWT.error(SWT.java:4276)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.jface.dialogs.MessageDialog.open(MessageDialog.java:334)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.informUser(CompletionProposalComputerRegistry.java:465)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:354)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1460)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1449)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:375)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
Caused by: java.lang.NullPointerException
at org.eclipse.ui.texteditor.AbstractTextEditor$9.run(AbstractTextEditor.java:625)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 40 more

!ENTRY org.eclipse.ui 4 0 2012-09-07 14:08:16.857
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.core.runtime.AssertionFailedException: assertion failed: )
at org.eclipse.swt.SWT.error(SWT.java:4361)
at org.eclipse.swt.SWT.error(SWT.java:4276)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.jface.dialogs.MessageDialog.open(MessageDialog.java:334)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.informUser(CompletionProposalComputerRegistry.java:465)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:354)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1460)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1449)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:375)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.jface.text.source.AnnotationModel.getRegionAnnotationIterator(AnnotationModel.java:742)
at org.eclipse.jface.text.source.AnnotationModel.getAnnotationIterator(AnnotationModel.java:700)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.getAnnotation(JavaEditor.java:3921)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.updateStatusLine(JavaEditor.java:3601)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.selectionChanged(JavaEditor.java:2295)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$2.run(CompilationUnitEditor.java:1672)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 40 more

!ENTRY org.eclipse.ui 4 0 2012-09-07 14:08:17.163
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.core.runtime.AssertionFailedException: assertion failed: )
at org.eclipse.swt.SWT.error(SWT.java:4361)
at org.eclipse.swt.SWT.error(SWT.java:4276)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.jface.text.source.AnnotationModel.getRegionAnnotationIterator(AnnotationModel.java:742)
at org.eclipse.jface.text.source.AnnotationModel.getAnnotationIterator(AnnotationModel.java:700)
at org.eclipse.jface.text.source.AnnotationRulerColumn.doPaint1(AnnotationRulerColumn.java:727)
at org.eclipse.jface.text.source.AnnotationRulerColumn.doubleBufferPaint(AnnotationRulerColumn.java:541)
at org.eclipse.jface.text.source.AnnotationRulerColumn.access$3(AnnotationRulerColumn.java:517)
at org.eclipse.jface.text.source.AnnotationRulerColumn$1.paintControl(AnnotationRulerColumn.java:289)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:230)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4134)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
at org.eclipse.swt.widgets.Control.drawWidget(Control.java:1244)
at org.eclipse.swt.widgets.Canvas.drawWidget(Canvas.java:163)
at org.eclipse.swt.widgets.Widget.drawRect(Widget.java:741)
at org.eclipse.swt.widgets.Canvas.drawRect(Canvas.java:158)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5471)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSView.displayIfNeeded(NSView.java:142)
at org.eclipse.swt.widgets.Control.update(Control.java:4904)
at org.eclipse.swt.widgets.Display.update(Display.java:4726)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:832)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.jface.dialogs.MessageDialog.open(MessageDialog.java:334)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.informUser(CompletionProposalComputerRegistry.java:465)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:354)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1460)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1449)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:375)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 23 more

!ENTRY org.eclipse.ui 4 4 2012-09-07 14:08:24.864
!MESSAGE Save Failed

!ENTRY org.eclipse.ui 2 0 2012-09-07 14:08:24.864
!MESSAGE Save Failed
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.ui.texteditor.AbstractMarkerAnnotationModel.updateMarkers(AbstractMarkerAnnotationModel.java:550)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.commitWorkingCopy(CompilationUnitDocumentProvider.java:1401)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$4.execute(CompilationUnitDocumentProvider.java:1449)
at org.eclipse.ui.editors.text.TextFileDocumentProvider$DocumentProviderOperation.run(TextFileDocumentProvider.java:132)
at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:456)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument(TextFileDocumentProvider.java:772)
at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5066)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSave(CompilationUnitEditor.java:1247)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:1301)
at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7198)
at org.eclipse.ui.Saveable.doSave(Saveable.java:214)
at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:346)
at org.eclipse.ui.internal.SaveableHelper$3.run(SaveableHelper.java:193)
at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:274)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
at org.eclipse.ui.internal.WorkbenchWindow$13.run(WorkbenchWindow.java:1666)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1663)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:282)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:261)
at org.eclipse.ui.internal.SaveableHelper.saveModels(SaveableHelper.java:204)
at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:144)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.doSave(CompatibilityPart.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:235)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:199)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:89)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.savePart(PartServiceImpl.java:1154)
at org.eclipse.ui.internal.WorkbenchPage.saveSaveable(WorkbenchPage.java:3459)
at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3477)
at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:76)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1072)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4133)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1495)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1491)
at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:493)
at org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1060)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5585)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5495)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:221)
at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2102)
at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2284)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5557)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:5002)
at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5151)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3616)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
new-host-6:.metadata rmangi$
new-host-6:.metadata rmangi$ !tail
tail -500 .log
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
Caused by: java.lang.NullPointerException
at org.eclipse.ui.texteditor.AbstractTextEditor$9.run(AbstractTextEditor.java:625)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 40 more

!ENTRY org.eclipse.ui 4 0 2012-09-07 14:08:16.857
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.core.runtime.AssertionFailedException: assertion failed: )
at org.eclipse.swt.SWT.error(SWT.java:4361)
at org.eclipse.swt.SWT.error(SWT.java:4276)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.jface.dialogs.MessageDialog.open(MessageDialog.java:334)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.informUser(CompletionProposalComputerRegistry.java:465)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:354)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1460)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1449)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:375)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.jface.text.source.AnnotationModel.getRegionAnnotationIterator(AnnotationModel.java:742)
at org.eclipse.jface.text.source.AnnotationModel.getAnnotationIterator(AnnotationModel.java:700)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.getAnnotation(JavaEditor.java:3921)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.updateStatusLine(JavaEditor.java:3601)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.selectionChanged(JavaEditor.java:2295)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$2.run(CompilationUnitEditor.java:1672)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 40 more

!ENTRY org.eclipse.ui 4 0 2012-09-07 14:08:17.163
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.core.runtime.AssertionFailedException: assertion failed: )
at org.eclipse.swt.SWT.error(SWT.java:4361)
at org.eclipse.swt.SWT.error(SWT.java:4276)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3944)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.jface.text.source.AnnotationModel.getRegionAnnotationIterator(AnnotationModel.java:742)
at org.eclipse.jface.text.source.AnnotationModel.getAnnotationIterator(AnnotationModel.java:700)
at org.eclipse.jface.text.source.AnnotationRulerColumn.doPaint1(AnnotationRulerColumn.java:727)
at org.eclipse.jface.text.source.AnnotationRulerColumn.doubleBufferPaint(AnnotationRulerColumn.java:541)
at org.eclipse.jface.text.source.AnnotationRulerColumn.access$3(AnnotationRulerColumn.java:517)
at org.eclipse.jface.text.source.AnnotationRulerColumn$1.paintControl(AnnotationRulerColumn.java:289)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:230)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4134)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
at org.eclipse.swt.widgets.Control.drawWidget(Control.java:1244)
at org.eclipse.swt.widgets.Canvas.drawWidget(Canvas.java:163)
at org.eclipse.swt.widgets.Widget.drawRect(Widget.java:741)
at org.eclipse.swt.widgets.Canvas.drawRect(Canvas.java:158)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5471)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSView.displayIfNeeded(NSView.java:142)
at org.eclipse.swt.widgets.Control.update(Control.java:4904)
at org.eclipse.swt.widgets.Display.update(Display.java:4726)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:832)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.jface.dialogs.MessageDialog.open(MessageDialog.java:334)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.informUser(CompletionProposalComputerRegistry.java:465)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:354)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:330)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:300)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:256)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1460)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1449)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:375)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 23 more

!ENTRY org.eclipse.ui 4 4 2012-09-07 14:08:24.864
!MESSAGE Save Failed

!ENTRY org.eclipse.ui 2 0 2012-09-07 14:08:24.864
!MESSAGE Save Failed
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.ui.texteditor.AbstractMarkerAnnotationModel.updateMarkers(AbstractMarkerAnnotationModel.java:550)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.commitWorkingCopy(CompilationUnitDocumentProvider.java:1401)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$4.execute(CompilationUnitDocumentProvider.java:1449)
at org.eclipse.ui.editors.text.TextFileDocumentProvider$DocumentProviderOperation.run(TextFileDocumentProvider.java:132)
at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:456)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument(TextFileDocumentProvider.java:772)
at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5066)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSave(CompilationUnitEditor.java:1247)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:1301)
at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7198)
at org.eclipse.ui.Saveable.doSave(Saveable.java:214)
at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:346)
at org.eclipse.ui.internal.SaveableHelper$3.run(SaveableHelper.java:193)
at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:274)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
at org.eclipse.ui.internal.WorkbenchWindow$13.run(WorkbenchWindow.java:1666)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1663)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:282)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:261)
at org.eclipse.ui.internal.SaveableHelper.saveModels(SaveableHelper.java:204)
at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:144)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.doSave(CompatibilityPart.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:235)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:199)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:89)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.savePart(PartServiceImpl.java:1154)
at org.eclipse.ui.internal.WorkbenchPage.saveSaveable(WorkbenchPage.java:3459)
at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3477)
at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:76)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1072)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4133)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1495)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1491)
at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:493)
at org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1060)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5585)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5495)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:221)
at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2102)
at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2284)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5557)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:5002)
at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5151)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3616)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

!ENTRY org.eclipse.ui 4 4 2012-09-07 14:12:24.440
!MESSAGE Save Failed

!ENTRY org.eclipse.ui 2 0 2012-09-07 14:12:24.440
!MESSAGE Save Failed
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.ui.texteditor.AbstractMarkerAnnotationModel.updateMarkers(AbstractMarkerAnnotationModel.java:550)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.commitWorkingCopy(CompilationUnitDocumentProvider.java:1401)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$4.execute(CompilationUnitDocumentProvider.java:1449)
at org.eclipse.ui.editors.text.TextFileDocumentProvider$DocumentProviderOperation.run(TextFileDocumentProvider.java:132)
at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:456)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument(TextFileDocumentProvider.java:772)
at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5066)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSave(CompilationUnitEditor.java:1247)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:1301)
at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7198)
at org.eclipse.ui.Saveable.doSave(Saveable.java:214)
at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:346)
at org.eclipse.ui.internal.SaveableHelper$3.run(SaveableHelper.java:193)
at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:274)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
at org.eclipse.ui.internal.WorkbenchWindow$13.run(WorkbenchWindow.java:1666)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1663)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:282)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:261)
at org.eclipse.ui.internal.SaveableHelper.saveModels(SaveableHelper.java:204)
at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:144)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.doSave(CompatibilityPart.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:235)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:199)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:89)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.savePart(PartServiceImpl.java:1154)
at org.eclipse.ui.internal.WorkbenchPage.saveSaveable(WorkbenchPage.java:3459)
at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3477)
at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:76)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1072)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4133)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1495)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1491)
at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:493)
at org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1060)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5585)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5495)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:221)
at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2102)
at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2284)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5557)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:5002)
at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5151)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3616)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

!ENTRY org.eclipse.ui 4 4 2012-09-07 14:12:28.252
!MESSAGE Save All Failed

!ENTRY org.eclipse.ui 2 0 2012-09-07 14:12:28.252
!MESSAGE Save All Failed
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at org.eclipse.ui.texteditor.AbstractMarkerAnnotationModel.updateMarkers(AbstractMarkerAnnotationModel.java:550)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.commitWorkingCopy(CompilationUnitDocumentProvider.java:1401)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$4.execute(CompilationUnitDocumentProvider.java:1449)
at org.eclipse.ui.editors.text.TextFileDocumentProvider$DocumentProviderOperation.run(TextFileDocumentProvider.java:132)
at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:456)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument(TextFileDocumentProvider.java:772)
at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5066)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSave(CompilationUnitEditor.java:1247)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:1301)
at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7198)
at org.eclipse.ui.Saveable.doSave(Saveable.java:214)
at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:346)
at org.eclipse.ui.internal.SaveablesList$3.run(SaveablesList.java:621)
at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:274)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
at org.eclipse.ui.internal.WorkbenchWindow$13.run(WorkbenchWindow.java:1666)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:1663)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:282)
at org.eclipse.ui.internal.SaveablesList.saveModels(SaveablesList.java:630)
at org.eclipse.ui.internal.SaveablesList.promptForSaving(SaveablesList.java:594)
at org.eclipse.ui.internal.SaveablesList.promptForSavingIfNecessary(SaveablesList.java:433)
at org.eclipse.ui.internal.SaveablesList.preCloseParts(SaveablesList.java:388)
at org.eclipse.ui.internal.SaveablesList.preCloseParts(SaveablesList.java:347)
at org.eclipse.ui.internal.WorkbenchPage.closeEditors(WorkbenchPage.java:1370)
at org.eclipse.ui.internal.WorkbenchPage.closeEditor(WorkbenchPage.java:1540)
at org.eclipse.ui.internal.CloseEditorHandler.execute(CloseEditorHandler.java:47)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:276)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:494)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:545)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:366)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:313)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:82)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1072)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4133)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1458)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1466)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1495)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1491)
at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:493)
at org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1060)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5585)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5495)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:221)
at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2102)
at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2284)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5557)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:5002)
at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5151)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3616)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

Comment by Andrew Eisenberg [ 07/Sep/12 ]

Looks like the exceptions after the first one are related to this bug. Have you updated to the latest Groovy-Eclipse snapshot? It is likely fixed in the snapshot.

As for the first exception, that's worth looking into as well. I need to know more information. Can you attach the file where this exception occurs?

Comment by Aled Sage [ 06/Oct/12 ]

Attached is my eclipse error log.

Contains one day's worth of errors - the last couple of exceptions are most pertinent to this bug.

Comment by Aled Sage [ 06/Oct/12 ]

Hi, thanks for the fixes in 2.7.1 - it works much better for me, but I still (less frequently) see these editor errors where it fails to save my file.

I'm using Using greclipse 2.7.1.xx.20120921-2000-e42RELEASE, with Eclipse SDK 4.2.1.M20120914-1800

I've attached my eclipse error log.

The exceptions I'm seeing look similar - should I re-open this bug, or is it a different cause warranting a new bug?

Comment by Andrew Eisenberg [ 07/Oct/12 ]

Re-opening this bug. Looks like I haven't found all situations where this exception is occurring. More information:

  1. Can you attach or send me directly one of the files where this is happening?
  2. Any save actions enabled? Eg, organize imports on save, format on save, etc?
  3. Error only happens on save, or other times too?
Comment by Aled Sage [ 07/Oct/12 ]

No save actions are enabled.

I've only noticed the error on save so far with 2.7.1.

With 2.6, I sometimes first noticed things were wrong when alt-uparrow reorder the lines; then on the next attempt to save it would lose the editor contents (so that at least gave me a chance to save my work to the clipboard!). But I haven't yet seen that behaviour with 2.7.1.

I'll take a copy of the groovy file next time I see it, and attach it here.

Comment by Andrew Eisenberg [ 12/Oct/12 ]

Any chance that your project or the problematic files use inner classes?

Comment by Aled Sage [ 12/Oct/12 ]

Hi, I have a groovy file for you where I've seen the error quite a few times. Unfortunately it's related to a customer so I can't share it here, but I can e-mail it to you in confidence.

However, the failures feel non-deterministic: each time I re-open the file and make what feels like the same edit, it works. I haven't managed to come up with any specific set of modifications that reliably breaks it.

My gut feel is that it is much more likely to happen if I've been writing some groovy code that, for some period of time, does not compile.

What is the best e-mail address to send it to?

Comment by Rick Mangi [ 12/Oct/12 ]

Updating groovy-eclipse eliminated this error for me. Hope that helps.

Comment by Aled Sage [ 12/Oct/12 ]

@Rick which version did you upgrade to - is it to snapshot? I'm getting the error with greclipse 2.7.1.

Comment by Rick Mangi [ 12/Oct/12 ]

I did upgrade to the snapshot but now I'm at the latest 2.7.2 release and no problems. (using GGTS) Upgrading fixed this problem for me on 2 different machines too.

Comment by Andrew Eisenberg [ 12/Oct/12 ]

@Aled,

andrew@eisenberg.as

@Rick,

Would be great if this fixes your problem, but it looks like others are having this problem with the latest snapshot. Worth a try, though.

Comment by Andrew Eisenberg [ 04/Feb/13 ]

Closing this as a duplicate of GRECLIPSE-1519. Please comment if you are still getting this problem.





[GRECLIPSE-1431] All plugins stop work when GRECLIPSE is installed on Eclipse --- Ubuntu APT distribution Created: 26/Apr/12  Updated: 31/Aug/12  Resolved: 31/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Anselmo F. Alvarez Jr. Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04 (Precise Pangolin), Eclipse 3.7.2 (Build id: I20110613-1736) by apt-get


Number of attachments : 0

 Description   

Steps to reproduce the issue:
1 - Get a clean eclipse install by APT (apt-get install eclipse)
2 - Help->Install New Software
3 - Using this update site http://dist.springsource.org/release/GRECLIPSE/e3.7/, install "Groovy-Eclipse (Required)". Restart Eclipse.
4 - In Help -> About Eclipse Platform, the groovy icon does not appear, but can be see in "Installation Details". I don't any plugin stuff like create a groovy project, create groovy class, etc.

If I try to install other plugins, and then install the groovy-eclipse, all other plugins stop to work, including the groovy-eclipse.



 Comments   
Comment by Andrew Eisenberg [ 26/Apr/12 ]

Make sure that you have installed Eclipse into a directory that is writable by the current user, otherwise Groovy-Eclipse will not install properly.

If that doesn't help. then maybe you are hitting this problem: http://groovy.codehaus.org/Eclipse+Plugin+FAQ#EclipsePluginFAQ-QIamrunningLinuxandcannotinstallGroovy-Eclipse

Comment by Anselmo F. Alvarez Jr. [ 27/Apr/12 ]

Andrew, there was a bug when try to install groovy-eclipse in ubuntu here: http://jira.codehaus.org/browse/GRECLIPSE-498

But since ubuntu 11.10 (Oneiric Ocelot) this bug apparently was solve and I can install successfully. But yesterday I have upgraded to the new Ubuntu and I see that my plugins have not started, but I can see that they are installed, the way I described above.

Comment by Andrew Eisenberg [ 27/Apr/12 ]

Is your install directory read-only?

Do you have any relevant errors in your error log?

Comment by Kris De Volder [ 27/Apr/12 ]

Note: Anselmo mentioned in his initial report:
> Eclipse 3.7.2 (Build id: I20110613-1736) by apt-get

I would recommend to not install Eclipse from the Ubuntu repos. Please try to use an Eclipse downloaded from eclipse.org instead. Also, because Greclipse installs a 'feature patch' as Andrew mentions it needs write access to where the eclipse is installed. My guess would be that the eclipse from Ubuntu repo is installed in the assumption that a single install will be shared by all users and this will probably mean that the installation is write protected and can't be extended with feature patches by individual users.

I work on Ubuntu (but I'm a bit behind on 10.04 . But I always just download an official eclipse.org eclipse and install it in my Home directory. That typically is the setup that gives me the least amount of headache.

I'm very distrustful of the repackaged versions in the Ubuntu repos.

Comment by Alaak D'Kar [ 04/May/12 ]

I used the Ubuntu packaged Eclipse for years now and at least for the last version (11.10) Groovy Eclipse worked perfectly together with it. But since after the upgrade to 12.04 it stopped working and shows the behaviour as explained above. .

Comment by Andrew Eisenberg [ 05/Jun/12 ]

Any updates on this? Have you tried using an eclipse from eclipse.org?

Comment by Anselmo F. Alvarez Jr. [ 05/Jun/12 ]

I give up.

I downloaded the last version in eclipse.org and install in writable directory.

But I really like to use the APT version (why? Because I think it's more organized, more clean).

I that hope one day may have a solution and I can try again.

Comment by Andrew Eisenberg [ 05/Jun/12 ]

Thanks for the feedback. Updating the title to make it more closely reflect the problem.

There is not too much that we can do. In the past, the problem was how the Ubuntu Eclipse was packaged with its own product feature, that made it not possible to install anything that upgraded the version of one of the core eclipse bundles. I don't know if this is the same problem popping up again, but it does seem to be something similar.

Your best bet is to raise a bug with the Ubuntu team that manages the Eclipse package.

Comment by Andrew Eisenberg [ 05/Jun/12 ]

Here is the previous issue that was raised on Ubuntu's bug tracker:
https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/575376

On a closer reading, it does look like a different problem.

Comment by Anselmo F. Alvarez Jr. [ 06/Jun/12 ]

Thanks Andrew for support, i will try open an issue in Ubuntu Bug Track.

Comment by Andrew Eisenberg [ 06/Jun/12 ]

And please, add a link to the bug report here.

Comment by Andrew Eisenberg [ 26/Jun/12 ]

Did you raise a bug report on the Ubuntu issue tracker?

Comment by Andrew Eisenberg [ 13/Jul/12 ]

Any update on this?

Comment by Anselmo F. Alvarez Jr. [ 14/Jul/12 ]

Andrew, really sorry for delay, but now I open an Issue on Ubuntu bugtrack: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/1024723

Comment by Andrew Eisenberg [ 31/Aug/12 ]

I'd recommend moving to Eclipse 4.2. In the latest version of Eclipse, they have done some good work making feature patches installable in read-only directories. This is likely the problem that you are seeing.

Comment by Andrew Eisenberg [ 31/Aug/12 ]

I am resolving this issue because there is not much we can do inside Groovy-Eclipse. I am willing to help with the ubuntu team if they have any questions and I will post there.





[GRECLIPSE-1427] Formatting multi-line list with as Object[] produces a compilation error Created: 20/Apr/12  Updated: 02/Oct/12  Resolved: 02/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Formatting
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Critical
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

After formatting the following script:

def test() {
    [
        1,
        2,
        3
    ] as Object[]
}

The following source is produced:

def test() {
    [
        1,
        2,
        3
    ]
    as Object[]
}

The error is on as Object[] with the message Groovy:unexpected token: as @ line 9, column 5



 Comments   
Comment by Bob Tiernay [ 20/Apr/12 ]

Something that might help to debug this is the following:

def f() {
    if (true)
        println 1

    1.each {
        1.each {
            [
                1
            ] as List
        }
    }
}

Formatting the above moves the println 1 call to the same indent as the if. I was able to narrow things down to this structure based on a real class of mine.

Comment by Andrew Eisenberg [ 24/Apr/12 ]

Kris, this seems like it is more your area.

Comment by Bob Tiernay [ 24/Apr/12 ]

I have come across issues with GRECLIPSE being unable to save a file and at time, totally freezing up eclipse. Due to the complexity of the source file I was editing it was difficult to narrow down the feature that caused the issue. I have a good feeling it was due to this issue. For now, I have replaced all [...] as Object[] with [...].asType(Object[]). I will post back if I determine that this fixed the problem.

Comment by Andrew Eisenberg [ 30/Sep/12 ]

I have a fix for this locally and will push tomorrow. I am fixing this particular issue and not anything more general than having an as literal immediately after a list literal. I don't think there is anything more general to fix, but if there is, I haven't fixed it. And if you can think of any, let me know.

Comment by Andrew Eisenberg [ 30/Sep/12 ]

I will get this in for the 2.7.2 release.

Comment by Andrew Eisenberg [ 02/Oct/12 ]

Done. Committed with regression tests. Will be available in next snapshot.





[GRECLIPSE-1424] Problems with FindSurroundingNode Created: 13/Apr/12  Updated: 13/Apr/12  Resolved: 13/Apr/12

Status: Resolved
Project: GRECLIPSE
Component/s: Search
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There are some problems with the FindSurroundingNode class. It fails to find nodes that are inside prefix or postfix expressions. This is because of a misplaced super call in some of the visit methods.

I have a fix and am almost through writing the tests.



 Comments   
Comment by Andrew Eisenberg [ 13/Apr/12 ]

GRECLIPSE-1425 describes some bugs in the source locations that I discovered while working on the tests.

Comment by Andrew Eisenberg [ 13/Apr/12 ]

Committed the fix with regression tests. No regression tests for he elvis and ternary operators since they are still broken under GRECLIPSE-1425.





[GRECLIPSE-1423] Save operation does save the file, but the editor is left dirty Created: 12/Apr/12  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I have a Groovy source file in my workspace that, whenever I change it and hit Ctrl+S to save, the file is saved, but the editor is kept dirty ("*" in the editor title).

The issue is caused by the following strange behaviour. On every save, the following lines are re-formatted:

ModelConversionImplG(){
	basicProfilefactories[SoloArtist.class] = {
		return new SoloArtistBean(defaultSongLicense: it.defaultSongLicense,
		foundationDate: it.foundationDate, dissolutionDate: it.dissolutionDate)
	} as BasicProfileBeanFactory;
	basicProfilefactories[Band.class] = {
		return new BandBean(defaultSongLicense: it.defaultSongLicense,
		foundationDate: it.foundationDate, dissolutionDate: it.dissolutionDate)
	} as BasicProfileBeanFactory;
	basicProfilefactories[Listener.class] = {
		return new ListenerBean() } as BasicProfileBeanFactory;
	basicProfilefactories[Club.class] = {
		return new ClubBean(googleMapsAddress:it.googleMapsAddress)
	} as BasicProfileBeanFactory;
}

On even saves, the code looks like that. On odd saves, it's reformatted as such:

ModelConversionImplG(){
	basicProfilefactories[SoloArtist.class] = {
		return new SoloArtistBean(defaultSongLicense: it.defaultSongLicense,
		foundationDate: it.foundationDate, dissolutionDate: it.dissolutionDate)
	} as BasicProfileBeanFactory;
	basicProfilefactories[Band.class] = {
		return new BandBean(defaultSongLicense: it.defaultSongLicense,
		foundationDate: it.foundationDate, dissolutionDate: it.dissolutionDate)
	} as BasicProfileBeanFactory;
	basicProfilefactories[Listener.class] = { return new ListenerBean() } as BasicProfileBeanFactory;
	basicProfilefactories[Club.class] = {
		return new ClubBean(googleMapsAddress:it.googleMapsAddress)
	} as BasicProfileBeanFactory;
}

So, there seems to be two problems here:

  • the formatter is formatting the same code differently on every save operation, guaranteeing the same formatting on every other save
  • the editor is left dirty after the formatting operation has finished

I have some save actions enabled but I don't know which of them are causing this. I may export the Eclipse formatter settings if you need further details.



 Comments   
Comment by Andrew Eisenberg [ 12/Apr/12 ]

Are there any errors in your error log?

Comment by Mauro Molinari [ 13/Apr/12 ]

Sorry, I forgot to mention: no, there are no errors in the error log.

Comment by Andrew Eisenberg [ 27/Apr/12 ]

I'm able to reproduce this. I am using the following code to avoid compile errors:

ModelConversionImplG(){
	basicProfilefactories[SoloArtist.class] = {
		return new SoloArtistBean(defaultSongLicense: it.defaultSongLicense,
		foundationDate: it.foundationDate, dissolutionDate: it.dissolutionDate)
	} as BasicProfileBeanFactory;
	basicProfilefactories[Band.class] = {
		return new BandBean(defaultSongLicense: it.defaultSongLicense,
		foundationDate: it.foundationDate, dissolutionDate: it.dissolutionDate)
	} as BasicProfileBeanFactory;
	basicProfilefactories[Listener.class] = { return new ListenerBean() } as BasicProfileBeanFactory;
	basicProfilefactories[Club.class] = {
		return new ClubBean(googleMapsAddress:it.googleMapsAddress)
	} as BasicProfileBeanFactory;
}
class ClubBean {
}
class SoloArtistBean {
}
class Band {
}
class BandBean {
}
class ListenerBean {
}
class Club {
}
class BasicProfileBeanFactory{
}

I am also using the following save actions (the contents of my .settings/org.eclipse.jdt.ui file):

eclipse.preferences.version=1
editor_save_participant_org.eclipse.jdt.ui.postsavelistener.cleanup=true
sp_cleanup.add_default_serial_version_id=true
sp_cleanup.add_generated_serial_version_id=false
sp_cleanup.add_missing_annotations=true
sp_cleanup.add_missing_deprecated_annotations=true
sp_cleanup.add_missing_methods=false
sp_cleanup.add_missing_nls_tags=false
sp_cleanup.add_missing_override_annotations=true
sp_cleanup.add_missing_override_annotations_interface_methods=true
sp_cleanup.add_serial_version_id=false
sp_cleanup.always_use_blocks=true
sp_cleanup.always_use_parentheses_in_expressions=false
sp_cleanup.always_use_this_for_non_static_field_access=false
sp_cleanup.always_use_this_for_non_static_method_access=false
sp_cleanup.convert_to_enhanced_for_loop=false
sp_cleanup.correct_indentation=false
sp_cleanup.format_source_code=true
sp_cleanup.format_source_code_changes_only=false
sp_cleanup.make_local_variable_final=false
sp_cleanup.make_parameters_final=false
sp_cleanup.make_private_fields_final=true
sp_cleanup.make_type_abstract_if_missing_method=false
sp_cleanup.make_variable_declarations_final=true
sp_cleanup.never_use_blocks=false
sp_cleanup.never_use_parentheses_in_expressions=true
sp_cleanup.on_save_use_additional_actions=true
sp_cleanup.organize_imports=true
sp_cleanup.qualify_static_field_accesses_with_declaring_class=false
sp_cleanup.qualify_static_member_accesses_through_instances_with_declaring_class=true
sp_cleanup.qualify_static_member_accesses_through_subtypes_with_declaring_class=true
sp_cleanup.qualify_static_member_accesses_with_declaring_class=false
sp_cleanup.qualify_static_method_accesses_with_declaring_class=false
sp_cleanup.remove_private_constructors=true
sp_cleanup.remove_trailing_whitespaces=false
sp_cleanup.remove_trailing_whitespaces_all=true
sp_cleanup.remove_trailing_whitespaces_ignore_empty=false
sp_cleanup.remove_unnecessary_casts=true
sp_cleanup.remove_unnecessary_nls_tags=false
sp_cleanup.remove_unused_imports=false
sp_cleanup.remove_unused_local_variables=false
sp_cleanup.remove_unused_private_fields=true
sp_cleanup.remove_unused_private_members=false
sp_cleanup.remove_unused_private_methods=true
sp_cleanup.remove_unused_private_types=true
sp_cleanup.sort_members=false
sp_cleanup.sort_members_all=false
sp_cleanup.use_blocks=false
sp_cleanup.use_blocks_only_for_return_and_throw=false
sp_cleanup.use_parentheses_in_expressions=false
sp_cleanup.use_this_for_non_static_field_access=false
sp_cleanup.use_this_for_non_static_field_access_only_if_necessary=true
sp_cleanup.use_this_for_non_static_method_access=false
sp_cleanup.use_this_for_non_static_method_access_only_if_necessary=true

My guess is that there is something wrong with the formatter in that it processes the same structure in different ways depending on initial whitespace.

Comment by Andrew Eisenberg [ 27/Apr/12 ]

Narrowed it down to this:

a = { 0 } as B

Note that B is not a valid class name. If I create a B class, then CMD+S will actually save the file, but on alternate saves the formatting changes.

Comment by Andrew Eisenberg [ 27/Apr/12 ]

From what I can see, the editor only stays dirty if there is a compile error. I dug a bit to see why this might be happening and it seems that the compile error causes an invalid piece of Java structure to be created. This causes the buffer that contains that structure to be closed. With a closed buffer, the editor thinks it has no changes.

It's a bit of a confusing path that gets taken since because save actions are enabled the file is semantically analyzed before saving.

I'll have a look at the formatting problem, but I my initial guess is that it is completely unrelated.

Comment by Andrew Eisenberg [ 19/Mar/13 ]

Confirmed fixed. I think this problem was related to GRECLIPSE-1519, which is now fixed as well.





[GRECLIPSE-1422] Content Assist displaying duplicates Created: 11/Apr/12  Updated: 05/Jun/12  Resolved: 05/Jun/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Minor
Reporter: E.G. Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse IDE for Java Developers - Windows 64 Bit
Java SE Development Kit 7u3 - Windows x64 (64-bit)


Attachments: PNG File eclipse-content_assist.png    
Number of attachments : 1

 Description   

When invoking the default content assist on a list, there are duplicate find and findAll methods displayed.



 Comments   
Comment by Andrew Eisenberg [ 05/Jun/12 ]

The reason why you are seeing these duplicates is that there are two find* DGMs that are applicable at this location for each name. Eg-

  • public static Collection findAll(Object self)
  • public static <T> Collection<T> findAll(Collection<T> self)

Obviously, this is confusing especially since at runtime, the second variant will be chosen. We should be able to filter out the less specific variants of DGMs.

Comment by E.G. [ 05/Jun/12 ]

Thanks for the update. It makes sense now.

I look forward seeing that filtering in the future.

Comment by Andrew Eisenberg [ 05/Jun/12 ]

Well, you don't have to look much longer. I released a fix and it will be available in the next build.

Now, if we find 2 category methods with the same name and parameter types (excluding the first parameter), then we remove one of them. This could be done a little better since we arbitrarily remove the second. We should be comparing types of the first parameter and keeping the method variant that has the more specific first parameter. I did not implement this, and I think what I have now is sufficient. If you want to see a more precise solution, please open a new issue for that.

Comment by E.G. [ 05/Jun/12 ]

That solution suites me just fine. Thanks again for the fix!





[GRECLIPSE-1421] groovy-eclipse.jar breaks public class EmptyExpression Created: 11/Apr/12  Updated: 12/Apr/12  Resolved: 12/Apr/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Sébastien Blanc Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: breaking
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7 / indigo


Number of attachments : 0

 Description   

We have custom plugin which uses the Groovy Plugin to compile Groovy Scripts with java based code. We also have some compiler customizers performing AST visits on the script. But groovy-eclipse.jar has its own EmptyExpression class which causes on our side a : java.lang.AbstractMethodError
at org.codehaus.groovy.ast.expr.EmptyExpression.visit(EmptyExpression.java:39)

A discussed this issue on the ML with Andy Clement and he suggest me to raise a Jira.



 Comments   
Comment by Andrew Eisenberg [ 11/Apr/12 ]

Our EmptyExpression class calls org.codehaus.groovy.ast.GroovyCodeVisitor.visitEmptyExpression(EmptyExpression), which is a method that doesn't exist in the original groovy.jar.

It looks like you have implemented GroovyCodeVisitor, but did not sub-class CodeVisitorSupport, which provides a default empty implementation.

Simple workaround: implement org.codehaus.groovy.ast.GroovyCodeVisitor.visitEmptyExpression(EmptyExpression) in your code as an empty method, but do not include an override annotation. OR, sub-class CodeVisitorSupport.

THe actual fix is to remove the method declaration from the GroovyCodeVisitor interface and change the method body in EmptyExpression.visit to use an instanceof check before invoking the visitor.

Comment by Sébastien Blanc [ 12/Apr/12 ]

Hi Andrew,
Your workaround works and so we can go further, thanks.
About the actual fix, are you suggesting a change in Groovy core ? Is this something we can propose for Groovy 2.0 ? I can start a discussion on the Groovy ML and propose a pull request.

Comment by Andrew Eisenberg [ 12/Apr/12 ]

Committed a fix. Will be available in next dev build. Let me know if you get a chance to try it out.

Comment by Andrew Eisenberg [ 12/Apr/12 ]

No, the fix I implemented is purely a workaround in Groovy-Eclipse. We could not introduce this change back into groovy-core for the 1.8 stream since it would break API. But, making it available in the 2.0 stream would be good. Feel free to mention this on the mailing list. I'm on vacation now, so I don't really have time to do this myself.





[GRECLIPSE-1420] Internal errors in Groovy compiler not reported in Eclipse Created: 10/Apr/12  Updated: 05/Jun/12  Resolved: 05/Jun/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Jan Stette Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS/X Lion, Eclipse 3.7.2


Issue Links:
Related
is related to GROOVY-5500 GroovyBugError thrown when it shouldn... Closed
Number of attachments : 0

 Description   

If I have the following code in a Groovy class in an Eclipse project:

print "Foo" ===~ ".*"

...then this produces an internal error in the Groovy compiler when using Groovy version 1.8.6 (see stack trace below). However, this error is not reported in Eclipse. Instead, the class file for the file that contains this code isn't generated, hence other code that uses this class starts reporting errors.

This makes it very hard for a user to understand what's going on; only when trying to compile the offending file with the command line compiler does it become obvious what's happening. So I presume that Groovy-Eclipse ought to pick up such errors from the compiler and report them alongside other errors in Eclipse?

Stack trace:

>>> a serious error occurred: BUG! exception in phase 'class generation' in source unit '<...>Foo.groovy' Operation: ("===" at 2:13: "===" ) not supported
>>> stacktrace:
BUG! exception in phase 'class generation' in source unit '/Users/jans/src/courses/nlp-class/week4/pa4-ner/java/GroovyTest.groovy' Operation: ("===" at 2:13: "===" ) not supported
at org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:246)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:521)
at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
at org.codehaus.groovy.classgen.asm.CallSiteWriter.makeCallSite(CallSiteWriter.java:301)
at org.codehaus.groovy.classgen.asm.InvocationWriter.makeCall(InvocationWriter.java:187)
at org.codehaus.groovy.classgen.asm.InvocationWriter.makeCall(InvocationWriter.java:89)
at org.codehaus.groovy.classgen.asm.InvocationWriter.makeInvokeMethodCall(InvocationWriter.java:73)
at org.codehaus.groovy.classgen.asm.InvocationWriter.writeInvokeMethod(InvocationWriter.java:292)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethodCallExpression(AsmClassGenerator.java:657)
at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
at org.codehaus.groovy.classgen.asm.StatementWriter.writeReturn(StatementWriter.java:577)
at org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeReturn(OptimizingStatementWriter.java:316)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitReturnStatement(AsmClassGenerator.java:499)
at org.codehaus.groovy.ast.stmt.ReturnStatement.visit(ReturnStatement.java:47)
at org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:80)
at org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:155)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:449)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:101)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:112)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:313)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:270)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:390)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1056)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174)
at org.codehaus.groovy.control.CompilationUnit$14.call(CompilationUnit.java:767)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:967)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:546)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:524)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:501)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:480)
at org.codehaus.groovy.tools.FileSystemCompiler.compile(FileSystemCompiler.java:60)
at org.codehaus.groovy.tools.FileSystemCompiler.doCompilation(FileSystemCompiler.java:216)
at org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompile(FileSystemCompiler.java:149)
at org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompileWithErrorHandling(FileSystemCompiler.java:179)
at org.codehaus.groovy.tools.FileSystemCompiler.main(FileSystemCompiler.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)



 Comments   
Comment by Andrew Eisenberg [ 05/Jun/12 ]

This is happening because the compiler is throwing an internal error on this bad syntax. Typically, we log internal errors in the error log, not in the file where the error comes from (since internal errors are not necessarily correlated with a file).

It seems to me that throwing an internal error here is not the right thing to do. Rather, a syntax error or something similar should be raised. These are handled correctly by our compiler.

I added a fix that will ensure that these {{GroovyBugError}}s are properly added to the list of compiler problems. Unfortunately, the error location will not be correct. I am closing this bug, but there is more work to do. I will raise an issue with groovy-core and see how we can raise a more appropriate compile error here.

Comment by Andrew Eisenberg [ 05/Jun/12 ]

Fixed. Will be available in next build.





[GRECLIPSE-1419] Groovy Eclipse plug-in On Eclipse3.7 Indigo has compatibility Issues not able to setup Groovy DEv Env Created: 30/Mar/12  Updated: 16/Jul/12  Resolved: 16/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution, Compiler Integration, Editor, Formatting, Project Settings
Affects Version/s: None
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: pushpesh sharma Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora 17 + Eclipse 3.7


Attachments: PNG File eclipse-error-openFile.png     PNG File eclipse_groovy_1.png     Text File GREclipse_error.log    
Number of attachments : 3

 Description   

1.I installed Eclipse using cmds:-
yum groupinstall 'Fedora Eclipse'
That gives me
Eclipse Version: 3.7.1
Build id: R3_7_1

2.Then I followed the steps available on link
http://docs.codehaus.org/display/GROOVY/Install+Groovy-Eclipse+Plugin
I used http://dist.springsource.org/milestone/GRECLIPSE/e3.7 URL for Update Site

3.Chosen Groovy Eclipse (Required)

4.Then I Created a Groovy Project as specified In the link
http://docs.codehaus.org/display/GROOVY/Create+Your+First+Groovy+Project

I got the error specified in the screen shot eclipse_groovy_1.png

5.Created a Groovy Class in this project,tried opening class file in editor got the error specified in the screen shot eclipse-error-openFile

6.I cleaned up all installation and tried with all URL download not the yum for installation got many similar issues .

7.Tried many times no success.



 Comments   
Comment by pushpesh sharma [ 30/Mar/12 ]

Please help me out with issue as soon as possible.I am new user, this is very frustrating effort it consumed my 20 Hrs or more

Comment by Andrew Eisenberg [ 30/Mar/12 ]

Can you open your error log and paste any relevant exceptions?

go to Windows -> Show view -> Other -> Error log.

Comment by Andrew Eisenberg [ 02/Apr/12 ]

Any progress here?

Comment by pushpesh sharma [ 02/Apr/12 ]

PFA for the GREclipse Error Log

Comment by Andrew Eisenberg [ 03/Apr/12 ]

From the error log, this looks like a permissions problem. Make sure that both your workspace (and all sub directories, particularly, .metadata) are writable by the current user. Also, make sure that your eclipse installation is writable as well.

Comment by Andrew Eisenberg [ 13/Jul/12 ]

Any update here?

Comment by pushpesh sharma [ 16/Jul/12 ]

The issue is resolved for me using eclipse indigo(Jar) and not installed from yum.Issue can be closed as I found this as known problem listed now in FAQ.

Comment by Andrew Eisenberg [ 16/Jul/12 ]

Thanks for getting back to me on this.





[GRECLIPSE-1418] groovy-eclipse-compiler incompatible with tycho 0.14.1 Created: 28/Mar/12  Updated: 31/Oct/12  Resolved: 31/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Pascal Rapicault Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive groovy.zip     Zip Archive working-tycho-groovy-project.zip    
Number of attachments : 2

 Description   

As part of a tycho build, I'm trying to build some groovy code. The compilation fails with the exception pasted below.
Please find attached a simple project allowing to reproduce the problem.

[DEBUG] Source roots:
[DEBUG] /Users/pascal/dev/tycho-tutorial/net.rapicault.tychotut.simpleGroovyProject/src
[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
[INFO] Compiling 1 source file to /Users/pascal/dev/tycho-tutorial/net.rapicault.tychotut.simpleGroovyProject/target/classes
[INFO] Classpath: /Users/pascal/dev/tycho-tutorial/net.rapicault.tychotut.simpleGroovyProject/target/classes:
[INFO] All args: [-cp, /Users/pascal/dev/tycho-tutorial/net.rapicault.tychotut.simpleGroovyProject/target/classes:, -d, /Users/pascal/dev/tycho-tutorial/net.rapicault.tychotut.simpleGroovyProject/target/classes, -g, -source, 1.6, -target, 1.6, -nowarn, -verbose]
Unrecognized option : -org.osgi.framework.system.packages
[INFO] Compilation complete. Compiled 0 files.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.663s
[INFO] Finished at: Wed Mar 28 22:28:50 EDT 2012
[INFO] Final Memory: 60M/118M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.14.1:compile (default-compile) on project net.rapicault.tychotut.simpleGroovyProject: Compilation failure: Compilation failure:
[ERROR] Found 0 errors and 0 warnings.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.14.1:compile (default-compile) on project net.rapicault.tychotut.simpleGroovyProject: Compilation failure
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)



 Comments   
Comment by Andrew Eisenberg [ 29/Mar/12 ]

It's strange. There is a compilation failure, but the reason for that failure is not being described. I originally thought that this was a variant of GRECLIPSE-1221 and so I added a java file, but the build is still broken. Even removing the groovy file and compiling results in the same error.

Comment by Andrew Eisenberg [ 30/Mar/12 ]

Finally got around to looking into this. Your project has 2 problems:

  1. You need to add a reference to org.codehaus.groovy in your manifest
  2. You need to add the http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7 repository

And I found one problem on our side. It looks like the org.osgi.framework.system.packages compiler option is not being recognized by our compiler. I'm having a deeper look to see why.

Comment by Andrew Eisenberg [ 30/Mar/12 ]

To be more clear about the problem, the compiler was failing because the system property was set, but it wasn't recognized. And, the failure message was not being properly created.

By simply ignoring the org.osgi.framework.system.packages option, I was able to get the build working. This is not a long term solution, but I will push this into the maven repo as a snapshot build and you can use this to fix your tutorial.

Here is the description of the system property:

The system property "org.osgi.framework.system.packages" allows the system bundle to export packages from the parent class loader. If we do not explicitly set this property Equinox will export all the packages visible to the parent class loader.

See http://old.nabble.com/Question-on-%22org.osgi.framework.system.packages%22-td22936822.html

This property is used by OSGI, but I am not sure how the JDT batch compiler uses it. I don't see any reference to that property in the batch compiler, so I am still a little confused.

Pascal, do you have any knowledge on how this property is generated by Tycho?

Comment by Andrew Eisenberg [ 31/Mar/12 ]

Ahh...I see the property is custom to Tycho's JDTCompiler class. The value of that property is set as the bootclasspathAccessRules and then passed to org.eclipse.tycho.compiler.jdt.CompilerMain, And this class has a org.eclipse.tycho.compiler.jdt.CompilerMain.handleBootclasspath(ArrayList, String) method that processes the access rules for the compiler.

It should be possible to do something similar for the groovy-eclipse-compiler. The current snapshot is working with tycho, but does not handle access rules.

Comment by Andrew Eisenberg [ 31/Oct/12 ]

Resolving this as fixed. Using tycho 0.16.0 and making the change to the pom and the manifest specified in earlier comments, the compilation succeeds.

Comment by Andrew Eisenberg [ 31/Oct/12 ]

Attaching the working project





[GRECLIPSE-1417] Rename of property variant fails to rename the getter Created: 25/Mar/12  Updated: 26/Mar/12  Resolved: 26/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider this code:

class Cat {
    static def getYY3(Other o) { }
}
class Other { }
new Other().yY3()

And this dsld:

contribute(currentType("Other")) {
    property( name:"yY3", declaringType: "Cat" )
}

Rename the yy3 variable reference and the declaring getYy3 should be renamed correctly, but it is not.



 Comments   
Comment by Andrew Eisenberg [ 26/Mar/12 ]

Fixed. Before starting a lightweight (ie- inplace) rename, check to see if the selected word matches the name of the element being renamed. If there is no match, then we are in a situation like this bug describes. In this case, do not do a light-weight rename. Instead, raise a dialog.





[GRECLIPSE-1416] Groovy Editor should offer variable name suggestion for typed variables Created: 23/Mar/12  Updated: 23/Mar/12  Resolved: 23/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Editor
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Minor
Reporter: Konstantinos Kostarellis Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: completion, editor
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.9.1, kubuntu 12.04 / osx 10.7.3 , jvm 1.6.24, grails 2.0.1, groovy 1.8.4


Issue Links:
Duplicate
duplicates GRECLIPSE-987 Code completion enters variable name ... Open
Number of attachments : 0

 Description   

Using eclipse to edit java classes: When creating a (typed) variable eclipse offers name suggestion for the variable name

e.g.

HolidayService <Ctrl+Space>
usually would offer the names "service" and "holidayService" as selectable suggestion. Further eclipse offers code-completion for the name if already started typing (hol <Ctrl+Space> -> holService, holidayService).

Its desirable to align the groovy editors behavior to the one for java files, to let the user work in an expected way.



 Comments   
Comment by Andrew Eisenberg [ 23/Mar/12 ]

I looked into this in the past. A solution is not as simple as I would have liked and I have not had a chance to implement the full thing. I'll have another look for 2.7.0.





[GRECLIPSE-1414] Doc hovers do not properly show hyperlinks inside of @link and @see Created: 22/Mar/12  Updated: 22/Mar/12  Resolved: 22/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Doc hovers do not show links for type references as the hovers of JDT show for Java. Example, here's a dsld:

contribute( currentType() ) {
    property( name:"harvey", type:String, doc: "{@link List}" )
}

Hovering over harvey in the following script:

this.harvey

The List should be clickable and when clicked, it should navigate to the javadoc for java.util.List.



 Comments   
Comment by Andrew Eisenberg [ 22/Mar/12 ]

Committed a fix. Will be available after next dev build is released.





[GRECLIPSE-1413] Quick Fix: Add Unimplemented Methods uses @override instead of @see Created: 20/Mar/12  Updated: 20/Mar/12  Resolved: 20/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Minor
Reporter: Roger Talkov Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse 3.7.2, windows 7


Number of attachments : 0

 Description   

I add a new method to an interface, then to correct the error in the implementing class I use Quick Fix: Add Unimplemented methods, it puts an @override above the method this is not correct as nothing is being overridden, instead there should either be nothing or a javadoc block with an @see for the interface method



 Comments   
Comment by Andrew Eisenberg [ 20/Mar/12 ]

The annotation will be added if your compliance level is set to Java 6 or higher. It will not be added if your compliance level is lower than that.

If you don't want this behavior, you can disable it for the project by going to Project properties -> Java Code Style. Deselect "Add @Override annotation". You also have the option of disabling it for the entire workspace.

Unfortunately, this option works both for Java and Groovy. So, you can't disable it for Groovy only.

This is working as designed. If you would like to see a separate option to disable this just for Groovy, please raise a new bug for this.

Comment by Roger Talkov [ 20/Mar/12 ]

After reading up more on @override, I see that it is used for implemetations of interface methods and that if I want to get an @see rather than using quick fix use source->Override/implement Methods and check the generate comments box





[GRECLIPSE-1412] Unable to resolve class in groovy scripts in different packages Created: 19/Mar/12  Updated: 23/Mar/12  Resolved: 23/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Critical
Reporter: Loris Chiocca Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File screenshot-1.jpg    
Issue Links:
Supercedes
is superceded by GRECLIPSE-1415 When one script refers to another scr... Open
Testcase included: yes
Number of attachments : 1

 Description   

I've got two simple groovy scripts.

ch.testing.Test1.groovy
package ch.testing

import ch.testing.util.Test2

def something() {
    Test2.doNothing()
}

and

ch.testing.util.Test2.groovy
package ch.testing.util

static def doNothing() {
}

When looking at eclipse a "Groovy: unable to resolve class ch.testing.util.Test2" on the import of Test1.groovy. Although executing "something()" actually executes, it shows a wrong statement about the script and the project having errors.



 Comments   
Comment by Loris Chiocca [ 19/Mar/12 ]

Forgot to state that if the two scripts are in the same package then it works. It only doesn't work if they are in different packages.

Comment by Andrew Eisenberg [ 20/Mar/12 ]

Hmmm...tried to reproduce this, but couldn't.

Do you have any errors in your error log and also, what is the exact version of Groovy-Eclipse that you are using?

Comment by Loris Chiocca [ 21/Mar/12 ]

Hi Andrew,

Sorry for not having specified the versions that I'm using. It's kind of silly of a programmer to have forgotten that

Here the version details:
eclipse: Eclipse Java EE IDE for Web Developers - Indigo Service Release 1 - Build id: 20110916-0149
groovy eclipse plugin: Version: 2.7.0.xx-20120315-1600-e37-RELEASE - Groovy version: org.codehaus.groovy
feature IDs: org.codehaus.groovy18.feature, org.codehaus.groovy.jdt.patch, org.codehaus.groovy17.feature, org.codehaus.groovy.eclipse.feature

I'm going to add a screenshot of the error I'm getting.

Cheers
Loris

Comment by Loris Chiocca [ 21/Mar/12 ]

Here's the screenshot. Hope you don't mind that I obfuscated a couple of things

Comment by Andrew Eisenberg [ 21/Mar/12 ]

I installed the version that you used and I still cannot reproduce.

What I find odd is that I was doing some work in a local branch (never actually committed) where I was able to reproduce your problem. But, undoing the changes and the problem went away. I had thought that perhaps I had accidentally committed these bad changes, but it doesn't look like it.

I'd recommend updating to the latest nightly build. It looks like you are already playing with snapshots, so I'm guessing that you know how to update again.

Also, please attach any potentially relevant entries from your error log: Window -> Show View -> Other... -> Error log.

Comment by Loris Chiocca [ 22/Mar/12 ]

Hi Andrew,

I've updated everything and am now using the following versions:
eclipse: Eclipse Java EE IDE for Web Developers - Indigo Service Release 2 - Build id: 20120216-1857
groovy eclipse plugin: 2.7.0.xx-20120316-1300-e37-RELEASE - Groovy version: org.codehaus.groovy
feature IDs: org.codehaus.groovy18.feature, org.codehaus.groovy.jdt.patch, org.codehaus.groovy17.feature, org.codehaus.groovy.eclipse.feature

After the update the error still happens and the error log is empty.

What else can I provide you with that would help debug this issue? If you want we can have a webex/teamviewer session and I can give you full control.

What I'll also try, is to reproduce it in a clean eclipse environment and then zip it and the workspace up so that you can have a go at it.

Cheers
Loris

Comment by Loris Chiocca [ 22/Mar/12 ]

All right... made a clean install of eclipse, the groovy plugin and a dummy project where the error occurs. I've uploaded it here:
https://www.wuala.com/lchiocca/Temp/GRECLIPSE-1412/?key=GRECLIPSE1412

Sometimes the error is gone, but as soon as you save the file it reappears.

Comment by Andrew Eisenberg [ 22/Mar/12 ]

I'm downloading your zip. If you're not on Mac, then I'll have to find another OS to use.

Comment by Andrew Eisenberg [ 22/Mar/12 ]

Ahhhh...I see the problem. You have script folders activated. See Preferences -> Groovy -> Compiler. What this means is that any groovy files in src/resources is considered a script. It is not compiled and the script itself is copied over to the output directory.

Since there is no class file, dependencies to other scripts cannot be tracked down.

So, the solution is to move these scripts from the script folder. If this is a requirement to keep them in the script folder, and they must be treated as scripts (ie- you don't want them to actually be compiled), then there might be some workaround that we can do.

Comment by Loris Chiocca [ 23/Mar/12 ]

Hi Andrew,

They should be scripts and need to be copied to the bin target. But the thing I don't get is that if the two scripts are in the same package (i.e. the same folder) the "class" resolution works and I don't get any errors. The best part is that the content assistent is actually aware of both scripts and proposes you the import or any method in those scripts.

Another thing I noticed is that if you turn off "groovy nature" of the project and immediately after that turn it back on, the error disapear until you change the file again.

If you're interested in our use-case: We have a java application where clients can write their own groovy scripts to plug in their own logic. So those scripts interact with java objects (through the bindings). To simplify the part our clients need to write, we have created a couple of utility scripts. These scripts reside in a separate package (hence the "ch.testing.util" ). Everything hooks up really well and everything get executed correctly. The only thing that bothers us is that during development we constantly have groovy scripts that show up as having errors. Hope that give a bit of background.

Comment by Loris Chiocca [ 23/Mar/12 ]

Wow... found something better. If you use the fully qualified script name and remove the import then it works as well. So if you change:

package ch.testing

import ch.testing.util.Test2

def something() {
    Test2.doNothing()
}

to

package ch.testing

//import ch.testing.util.Test2

def something() {
    ch.testing.util.Test2.doNothing()
}

then you don't get an error. So it's only a problem of the import statment checking.

Comment by Andrew Eisenberg [ 23/Mar/12 ]

Interesting...I see exactly what's going on here. There are two kinds of interesting operations:

  1. A compile: converts your script/class into a class file and places it into the output folder. In this case, the scripts in script folders are not actually copied to the output folder even though they are checked for compile errors. When there is an incremental compile of Test1, the compiler tries to resolve the import Test2 but can't since there is no corresponding class file in the output folder. Hence the error. On a full build where both Test1 and Test2 are compiled together, the resolution is slightly different. Resolution happens from source and since the source of Test2 exists, its reference in Test1 can be resolved and hence no error in this case.
  2. A reconcile: this happens while typing. It is an almost compile, except that no class files are written and resolution happens against source code (this is how it is possible to see unsaved changes in other files). It is used to find errors while you type and to get the information during content assist (and other things like this). In this case, resolution happens against other sources, so there are no errors found and content assist, underlines, etc work properly.

The problem is that during an incremental compile, we are finding the error simply because the referred file does not exist in the output folder. The errors are being recorded even though the reconcile finds no errors.

Two possible solutions:

  1. Don't record errors on scripts during compile
  2. Don't send scripts to the compiler, but do send them to the reconciler.

I'm closing this bug and opening a new one that correctly describes the problem you are seeing. Thanks for being patient and working through this with me.

Comment by Andrew Eisenberg [ 23/Mar/12 ]

Closing this as not-a-bug. Will open a new bug that correctly describes the problem.

Comment by Loris Chiocca [ 23/Mar/12 ]

Thanks for the help. I owe you a beer Awaiting the new issue

Comment by Andrew Eisenberg [ 23/Mar/12 ]

GRECLIPSE-1415





[GRECLIPSE-1411] Groovy Script outline is showing variables declared in closures at the same level as the 'enclosing' declaration Created: 16/Mar/12  Updated: 16/Mar/12  Resolved: 16/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
def doThat(fun) {
	File a = new File("That's a test")
	fun();
}

def x = doThat {
	File b = new File("That's a test")
}

doThat {
	File c = new File("That's a test")
}

Outline will show:

  • doThat
  • x
  • b
  • c

All at the same level.
Yet it doesn't show 'a' at all.

Arguably we don't want to show b and c at all.
(Or if we do show it, it should be nested under something, e.g. 'b' could be nested under 'x'.)



 Comments   
Comment by Kris De Volder [ 16/Mar/12 ]

Trivial fix committed.





[GRECLIPSE-1410] Unexpected results when reformatting multiline map Created: 15/Mar/12  Updated: 02/Oct/12  Resolved: 02/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Bob Tiernay [ 15/Mar/12 ]

Sorry, pressed enter too soon!

In the following script:

[
    a: 1,
    b: 2
]

after pressing Ctrl + Shift + F produces the following:

[
            a: 1,
            b: 2
        ]

Note the extra spaces introduced.

However, the following script:

[
    1,
    2
]

produces:

[1, 2]

As an aside, I would expect both examples not to change the source but at the very least they should be consistent

Comment by Bob Tiernay [ 15/Mar/12 ]

Might want to update the title to reflect the issue (and fix the spelling mistake)

Comment by Andrew Eisenberg [ 02/Oct/12 ]

Fixed. Will be available in next snapshot build.





[GRECLIPSE-1407] Yet another HTTP-Builder No Signature of Method: HTTPBuilder.request() is applicable for types Created: 15/Mar/12  Updated: 13/Jul/12  Resolved: 13/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Daniel Woods Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora 16 x64, jdk1.6.0_26 x64, eclipse indigo java ee x64, greclipse 2.6.1.xx-20120301


Number of attachments : 0

 Description   

Error:

Caught: groovy.lang.MissingMethodException: No signature of method: groovyx.net.http.HTTPBuilder.request() is applicable for argument types: (groovyx.net.http.Method, my.app$_myClosure_closure1) values: [GET, my.app$_myClosure_closure1@5492de02]
Possible solutions: request(groovyx.net.http.Method, groovy.lang.Closure), request(groovyx.net.http.Method, java.lang.Object, groovy.lang.Closure), request(java.lang.Object, groovyx.net.http.Method, java.lang.Object, groovy.lang.Closure)

def http = new HTTPBuilder(this.instanceUrl)
http.request(GET) { req ->
	uri.path  = '/services'
	uri.query = [q: query]
	
	response.success = { resp, reader ->
		assert resp.statusLine.statusCode == 200
		println reader.text
	} 
}

Script runs fine in console. This issue mirrors GRECLIPSE-1004, which says that 2.5.0 has the fix. This issue is close to GRECLIPSE-705, which says that 2.0.2 has the fix. Is there any workaround for the time being? Running as Java Application (which other issues similar to this one suggest is a workaround) does not work.



 Comments   
Comment by Andrew Eisenberg [ 15/Mar/12 ]

Are you using @Grab? Eclipse's support for @Grab is not complete and this could cause some problems.

Also, can you attach the full script of what is failing for you?

Comment by Daniel Woods [ 15/Mar/12 ]

I'm using maven for dependency management, and I think that dependencies were the root of my problem. I have it working now. I completely started over with a fresh install of Eclipse Indigo, added GREclipse support, maven support. Imported my project. For the modules that needed groovy support, at the module-level right click->Configure->convert to groovy project. If that's all that I did, then I would get the error above.

Next, it was necessary to add the following dependencies to my pom:

<dependency>
<groupId>org.codehaus.groovy.maven.runtime</groupId>
<artifactId>gmaven-runtime-default</artifactId>
<version>1.0-rc-3</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy.modules.http-builder</groupId>
<artifactId>http-builder</artifactId>
<version>0.5.2</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>1.7.0</version>
</dependency>
<dependency>
<groupId>commons-cli</groupId>
<artifactId>commons-cli</artifactId>
<version>1.2</version>
</dependency>

Only after this could I successfully run the script as a Groovy Script from within Eclipse.

Comment by Andrew Eisenberg [ 15/Mar/12 ]

Any chance you can attach the project so I can try this out myself?

Also, I'm not clear on your initial workflow was, the one that originally caused you problems. So, I'm not sure if there is room for improvement on Groovy-Eclipse's side. It does seem like if the dependencies are not set up properly, then we shouldn't expect the script to run at all.

Comment by Andrew Eisenberg [ 13/Jul/12 ]

Appears fixed. Please reopen if you continue to have problems.





[GRECLIPSE-1406] selectively allow some ast transforms to run during reconciling Created: 14/Mar/12  Updated: 15/Mar/12  Resolved: 14/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Minor
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes GRECLIPSE-1179 Selectively run "safe" ast transforms... Resolved
Number of attachments : 0

 Description   

This jira covers the work to selectively enable local ast transforms during reconciling. Currently non are allowed.



 Comments   
Comment by Andy Clement [ 14/Mar/12 ]

Committed first pass. New tests in FullProjectTests for this. New compiler option that can be set like other java compiler options.

In CompilerOptions:

 String OPTIONG_GroovyTransformsToRunOnReconcile = "org.eclipse.jdt.core.compiler.groovy.groovyTransformsToRunOnReconcile"; 

which can be initialized from a system property if not being set by another means:

greclipse.transformsDuringReconcile

The supported format right now is a comma separated list of strings. The strings are considered to be partial names, so if a transform has these strings anywhere in it, it is allowed. There are only two special characters right now:

Foo$ - a $ can be used to indicate this must be the last part of a transform name. So for @Singleton, Singleton$ wont match but SingletonASTTransformation$ would match.

  • - this will turn on all transforms. It can be supplied in a comma list but that doesn't really make sense as it will supercede all other specified values.




[GRECLIPSE-1404] Unresolvable types should be underlined Created: 13/Mar/12  Updated: 23/May/13  Resolved: 23/May/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: stability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script:

NotDefined variable

The "v" in variable is underlined. To be more consistent with the Java editor (and more directly indicate the source of the problem both visually and semantically) the editor should underline the type NotDefined



 Comments   
Comment by Andrew Eisenberg [ 13/Mar/12 ]

We get compiler errors directly from the compiler. So, to fix this, we will have to make changes to the compiler.

Comment by Andrew Eisenberg [ 22/Apr/13 ]

Greclipse should be smarter about transforming groovy compiler error messages into something more IDE friendly.

Comment by Andrew Eisenberg [ 23/May/13 ]

Now fixed. We have already done some work on error reporting and placing markers in appropriate locations.

Working for field declaration types, method return types, and local variable definitions.





[GRECLIPSE-1403] Extract method initially prompts the user to "Provide a 'variable' name" Created: 13/Mar/12  Updated: 14/Mar/12  Resolved: 14/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When extracting a method, the user is prompted to Provide a 'variable' name. This should probably read Provided a 'method' name



 Comments   
Comment by Andrew Eisenberg [ 14/Mar/12 ]

Fixed.





[GRECLIPSE-1400] Extra trailing space inserted after method completion with arguments Created: 13/Mar/12  Updated: 15/Mar/12  Resolved: 15/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File formatter.xml    
Number of attachments : 1

 Description   

In the following script:

f// Ctrl+Space, select f(int x), editor produces: f(0 )

def f(int x){}

An extra space is introduced after selecting f(int x):

f(0 )

def f(int x){}

Note, I have custom Java formatter settings active, but this isn't the behavior in the Java editor.



 Comments   
Comment by Andrew Eisenberg [ 14/Mar/12 ]

Using the default settings, I cannot reproduce. It could be that we are reading in some of the Java formatter settings and erroneously applying them where they shouldn't be.

Can you attach your java formatter settings and I will try it with that?

Comment by Bob Tiernay [ 14/Mar/12 ]

Attached formatter settings file

Comment by Andrew Eisenberg [ 15/Mar/12 ]

Seems to me that you have your formatter settings set to add an extra space after an opening paren and before a closing paren.

When I apply your formatting settings and I extract a method in pure Java, I see the same behavior in the new method call.

Comment by Bob Tiernay [ 15/Mar/12 ]

Interesting, I just tried this in the java editor and it doesn't happen for me. I tried extract method as well. Note, this issues was to do with auto-complete, however.

Comment by Bob Tiernay [ 15/Mar/12 ]

Note that in "White Space | Expressions > Parenthesized expressions" I have "after opening parenthesis" and "before closing parenthesis" checked, so this shouldn't be what you are seeing.

Comment by Andrew Eisenberg [ 15/Mar/12 ]

Oh...my mistake. I had fiddled with things and also confused things (looking at too many bugs at once).

Yes, it looks like groovy content assist does not respect the space after opening paren format option. I fixed that and it looks good. I'll play around a bit before committing.

Comment by Andrew Eisenberg [ 15/Mar/12 ]

As a side note, the groovy extract method does not respect these settings either. I'll see if it is an easy fix, otherwise, I'll open a new bug for it.

Comment by Andrew Eisenberg [ 15/Mar/12 ]

Now fixed for real. Will create a new bug for extract method, but this is actually a fair bit more complicated since we don't keep track of open/close paren spaces in general. We only do it for content assist since it was convenient to do so.





[GRECLIPSE-1399] Invalid semantic highlighting of static method declaration Created: 13/Mar/12  Updated: 14/Mar/12  Resolved: 14/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script, staticMethod is highlighted when it should not be:

static staticMethod() {}


 Comments   
Comment by Andrew Eisenberg [ 14/Mar/12 ]

What do you mean highlighted? Can you include a screenshot?

In my editor, staticMethod is italicized just like any other reference to a static member.

Comment by Bob Tiernay [ 14/Mar/12 ]

Sorry, that's what I meant. I thought this feature was called "semantic highlighting".

In the Java editor, static method definitions are not italicized, only their references are. That was the basis for this issue.

Comment by Andrew Eisenberg [ 14/Mar/12 ]

That's interesting. It's something I never noticed before. You're right.

The Java settings are specified in Preferences -> Java -> Editor -> Syntax Coloring. And Groovy inherits from there. There is a section for method and method invocation, another for static method invocation, but nothing for static method (declarations). There is field and static field, but no difference between the declaration and the reference.

It's confusing and inconsistent. but I will follow the lead of JDT in this case.

Comment by Andrew Eisenberg [ 14/Mar/12 ]

I forgot that Groovy-Eclipse does not actually distinguish (for semantic highlighting purposes) between method declarations and invocations and field declarations and references. The only options we have for highlighting members are field, static field, method, and static method. Since we don't actually distinguish between the situations described in this bug, I am inclined to close this bug as won't fix.

We already have other bugs open for this:
GRECLIPSE-948
GRECLIPSE-924

The problem in this bug can be folded into the problems described in the other bugs.





[GRECLIPSE-1398] NPE for annotation reference to constant in binary file Created: 13/Mar/12  Updated: 22/Apr/13  Resolved: 22/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As discussed here:
http://forum.springsource.org/showthread.php?124151-NullPointerException-at-AnnotationVisitor-getConstantExpression()

I have been able to recreate this now (with groovy 1.7) - it can happen when a reference is made into a binary groovy file from an annotation value.



 Comments   
Comment by Andy Clement [ 13/Mar/12 ]

it occurs because 1.7 isn't quite capturing class file constants correctly. For this code

class C {
  public final static String value = "abc";
}

groovy 1.7 produces this decompiled output:

public static final java.lang.String a;

whilst groovy 1.8 produces this decompiled output:

public static final java.lang.String a;
  Constant value: String hello

without the classfile capturing the 'constant-ness' we cannot (easily) work out what the value is from a purely static reference. The code in JDTClassNode.fieldBindingToFieldNode cannot cope with this situation. In my testcase I can only get the error on an incremental build (because at that point the class containing the constant only has a binary representation). I can imagine other situations where a reference is made into a jar containing the constant and that would cause all full builds to fail.

I'll spend a few mins thinking about solutions but we may have to just say this kind of thing isn't supported for 1.7.

Comment by Andy Clement [ 13/Mar/12 ]

I think we 'get away with it' for pure groovy compilation (where the reference to the constant is into something in a jar) because groovyc resolves references by loading classes and driving static initializers (yuck).

Comment by Andy Clement [ 13/Mar/12 ]

I can guard to catch the problem where the constant is not correctly represented, this at least causes a real message to come out rather than the NPE. The kind of messages that will come out in the situation are now:

/Project/src/A.groovy: 1 Groovy:expected 'Const.instance' to be an inline constant of type java.lang.String not a property expression in @Anno
/Project/src/A.groovy: -1 Groovy:Attribute 'value' should have type 'java.lang.String'; but found type 'java.lang.Object' in @Anno
Comment by Andy Clement [ 13/Mar/12 ]

committed a test and the guard. This all works fine on 1.8 so not currently going to do the heavy lifting to fix it for 1.7

Comment by Andrew Eisenberg [ 22/Apr/13 ]

Fixed.





[GRECLIPSE-1397] Extract Method action fails when one or more argument is an array Created: 11/Mar/12  Updated: 14/Mar/12  Resolved: 14/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Minor
Reporter: Tim Bain Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When I try to use the Extract Method refactoring action on a block of code where one or more arguments to the new method are arrays, the type of that argument in the refactoring dialog box is incorrect. For example, for this trivial code block:

String[] strings = null;
String str = null;
str = strings[0];

If I try to extract the final line into a new method called test, the dialog shows the argument type for the strings variable to be "String;" in the arguments list, but in the method signature preview, the method signature is "private test(String str, [Ljava.lang.String; strings)", and that's what you get in the code if you perform the refactoring.

Interestingly, passing in an array of ints instead of Strings gives a slightly different type (though it also fails). This code block:

int[] ints = null;
int i;
i = ints[0];

Yields an argument type of "[I" for the ints variable in both the argument list and the method preview.



 Comments   
Comment by Andrew Eisenberg [ 11/Mar/12 ]

Thanks for reporting this. The text you are seeing is the underlying Groovy/JVM type name for an array type. Should be relatively easy to fix.

Comment by Andrew Eisenberg [ 14/Mar/12 ]

I committed a fix for this. Will be working fine after the next CI build completes.





[GRECLIPSE-1396] Invalid deprecation warning for Date.parse(String, String) Created: 07/Mar/12  Updated: 11/Dec/14  Resolved: 02/Oct/14

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Denis Murashev
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script:

Date.parse("yyy-MM-dd", "2012-01-01")

Date.parse shows as deprecated. However, this overload of parse isn't deprecated. I realize there is some unfinished work with respect to overloaded methods, their types and resolution, but is there a way around this for a short list of useful methods?



 Comments   
Comment by Andrew Eisenberg [ 13/Jul/12 ]

Where does this parse method come from? I only see one parse method on java.util.Date (and it is deprecated).

Comment by Denis Murashev [ 27/May/14 ]

java.util.Date from Java JDK does not contain parse(String, String) method.
The mentioned method is from http://groovy.codehaus.org/groovy-jdk/java/util/Date.html#parse(java.lang.String, java.lang.String)
And that method is not deprecated.

Comment by Mauro Molinari [ 29/Sep/14 ]

Hi Denis, is version 2.9.1.xx-201408202052-e44 supposed to contain this fix? Because I can still reproduce.

Comment by Denis Murashev [ 29/Sep/14 ]

Hi Mauro, it looks like one of the subsequent changes in the code base breaks my initial fix. I'm going to fix it again.
Thank you very much for the information!

Comment by Denis Murashev [ 29/Sep/14 ]

The issue can be reproduced again

Comment by Mauro Molinari [ 20/Oct/14 ]

Now in 2.9.1.xx-201410031620-e44 this seems to work fine, thank you!

Comment by Mauro Molinari [ 11/Dec/14 ]

Hmmm... there are still problems here

Consider this class:

package g
class TestParseDate {

	public TestParseDate() {
		def a = Date.parse('', "")
	}
}

Here Greclipse does not show the deprecation hint. However, if you add @CompileStatic it does:

package g
import groovy.transform.CompileStatic;
@CompileStatic
class TestParseDate {

	public TestParseDate() {
		def a = Date.parse('', "")
	}
}

Also, I have a use case in a production product where the deprecation hint is shown even if I remove the @CompileStatic annotation, but I wasn't able to reproduce in a simple test case.

Comment by Mauro Molinari [ 11/Dec/14 ]

I got it, here is a test case that shows the deprecation warning even if @CompileStatic is absent:

package g
import groovy.transform.CompileStatic;
class TestParseDate {

	void loadFatture(int foo) {
		def a = Date.parse('yyyy-MM-dd', "$foo-01-01")
	}
}

The discriminant is the presence of $foo in the second GString.





[GRECLIPSE-1395] Move source repo to git Created: 06/Mar/12  Updated: 26/Jun/12  Resolved: 26/Jun/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We will be moving the Groovy-Eclipse source repository to git. Likely, the canonical repository will be located at github.



 Comments   
Comment by Russel Winder [ 07/Mar/12 ]

Couldn't the master repository be on Codehaus with a mirror for working on GitHub?

Comment by Andrew Eisenberg [ 07/Mar/12 ]

That is a possibility. What are the benefits for keeping the canonical source at codehaus?

Comment by Russel Winder [ 07/Mar/12 ]

One is quasi political – Codehaus supported Groovy, so it is good if Groovy-related project stay with Codehaus. Clearly GitHub is the place to hold the working master so people can clone and submit pull requests. Having the master master as a Codehaus project/repository makes it trivial to get artefacts into the Maven repository – something not entirely easy from GitHub. This last point is the second reason for staying at Codehaus.

Comment by Andrew Eisenberg [ 07/Mar/12 ]

First, groovy-eclipse does not produce maven artifacts. Well, groovy-eclipse-compiler and groovy-eclipse-batch are exceptions, but they are generated by a build process on my local machine and only done as needed.

I understand the political reason and I have indeed considered that, but so far, the infrastructure has not given me any particular confidence. For example, browsing via a webpage is currently disabled. Try to access any of the git urls in this page via a browser: http://docs.codehaus.org/display/GROOVY/Git

In theory I do want to support codehaus and leave the source code there, but there are no practical benefits for doing this. I'm willing for someone to convince me otherwise (so keep trying ) and I have talked to other members of the groovy team, but so far it does not seem like the right way to go.

Comment by Russel Winder [ 07/Mar/12 ]

Without artefacts to go into the Maven repository then the Codehaus repository holds little real appeal compared to housing the master at GitHub. Could always just house a mirror of the master at Codehaus for backup purposes?

Comment by Daniel Phan [ 16/Mar/12 ]

A subversion-to-git migration will need a translation for the author formats. Subversion uses usernames (e.g. "danielphan") and git uses full names with email addresses (e.g. "Daniel Phan <d3phan@uwaterloo.ca>"). Here's the list of authors that github found when attempting to import a repository there:

  • aclement
  • werdna
  • kdvolder
  • nisingh
  • surffan

I don't know if this list is complete.

I've also tried the import using the svn2git tool, but it seems it got stuck near the end. I'll log the output to a file this time to better diagnose what went wrong.

Comment by Konstantinos Kostarellis [ 24/Mar/12 ]

Hi Daniel,

the list of svn-users is complete. For fun I just did a migration of the svn (just trunk) to git. Resulting .git repo is 241M. It is so large because of the many (changing version of) libs/jars.
After that i did a

git log | grep Author: | sort | uniq

which resulted in:
Author: aclement <aclement@a5544e8c-8a19-0410-ba12-f9af4593a198>
Author: kdvolder <kdvolder@a5544e8c-8a19-0410-ba12-f9af4593a198>
Author: nisingh <nisingh@a5544e8c-8a19-0410-ba12-f9af4593a198>
Author: surffan <surffan@a5544e8c-8a19-0410-ba12-f9af4593a198>
Author: werdna <werdna@a5544e8c-8a19-0410-ba12-f9af4593a198>

The "strange" mail adresses were generated, cause I didn't have an authors translation file (Name + Email for each svn user).

I don't want to be smart-ass-ing here but maybe my tips are helpful: (Chances are high you know already all of that).

If you like you could go this route: In an empty folder

git svn init http://svn.codehaus.org/groovy/eclipse/trunk/
git svn fetch

after that you can add a remote and push all things you want there.
Also you can keep track of the svn until migration is all set by writing a cron job to keep up with trunk. Something like

git svn fetch
git merge git-svn
git push mainrepo master

Obviously you need to add that remote "mainrepo" before you can push.

Variations of the git svn init are to specify -t <tagfolder> and -T <trunk> separately and for sure -A authors.txt. In my experience svn-branches are usually less important ... but that is project-specific.

I guess you knew all or at least most of it ... but just for the case you didn't, i hope this can be helpful.

Cheers,
Kosta

Comment by Daniel Phan [ 27/Mar/12 ]

Thanks for this, I'm neither a git nor an svn expert so all information is helpful.

Comment by Andrew Eisenberg [ 27/Mar/12 ]

Thanks Konstaninos. This is useful information.

We moved repos in mid-2009 and we lost the history before then. 80% of the codebase has been re-written, but we did lose some history. So, we should have more than those 5 committers, but unfortunately, the information is in a separate svn repository.

As for the size of the git repo, I do want to keep the full history available. So, I don't think there is much we can do about pruning the size or removing older jars.

I'll start looking into the git migration next week.

Comment by Andrew Eisenberg [ 16/Apr/12 ]

I have been trying to run svn2git, but to no avail. It seems to be failing on some non-existant tag that it can't find.

I am falling back on running git svn instead. We don't need to include the branches since they are for eclipse versions that are no longer supported and I can add the tags in manually later. So, if git svn works, I will go that way.

Comment by Russel Winder [ 17/Apr/12 ]

Experience of past conversions is that "git svn" always ended up being my route. The main loss was the lack of conversion of Subversion commiter identifiers to Git commiter identifiers. The major problem with the whole repository conversions is usually that the Subversion state is actually inconsistent. This invariably happens with Subversion repositories converted from CVS, but also when various svnadmin hacks have been applied with older versions of Subversion.

Given that you are not looking to preserve and entire correct history, I'd go now with "git svn"

"git svn" has always managed to correctly enter all branches and tags for me as long as you have a canonically structured Subversion repository or you give all the correct Git command line arguments to offer up the Subversion branch and tag directories as well as the trunk directory.

Comment by Andrew Eisenberg [ 17/Apr/12 ]

git svn has finished. It ran over night. The tags were not included, neither were the branches, but that's fine. Author tags were included.

Unfortunately, the size of the repo is almost 1G. I'm not sure if there is a way to keep the size down without losing significant history.

Now that I have this repo available, I can keep it up to date with git svn rebase.

Comment by Russel Winder [ 17/Apr/12 ]

Please don't publish a repository you are going to rebase: rebasing is fine for private repositories but really ###### off people who have forks.

I guess the bulk of the 1GB is actually all the jars that got stored?

The Groovy Subversion store is a bit of a mess so some problems are to be expected, but you should have been able to give branch and tag directories (if there are any) and have them turned into branches and tags in the Git repository. But if this doesn't matter to you then no problem.

Comment by Andrew Eisenberg [ 04/May/12 ]

Canonical location of git repository is here:

https://github.com/groovy/groovy-eclipse

I will also keep a mirror at codehaus.org.

Pushing is happening as I write this. Once complete, and all is OK, I will resolve this bug.

Comment by Andrew Eisenberg [ 26/Jun/12 ]

Complete.





[GRECLIPSE-1394] Highlighting does not work, if one uses groovy-regexp ... Created: 06/Mar/12  Updated: 07/Mar/12  Resolved: 06/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Minor
Reporter: N K Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy-Eclipse Feature 2.6.1.xx-20120118-1100-e37-M1 org.codehaus.groovy.eclipse.feature.feature.group Codehaus.org


Attachments: JPEG File Unbenannt.jpg    
Issue Links:
Duplicate
duplicates GRECLIPSE-1203 Syntax highlight for slashed strings Resolved
Number of attachments : 1

 Description   

Have a look at the screenshot appending.



 Comments   
Comment by Andrew Eisenberg [ 06/Mar/12 ]

See GRECLIPSE-1203. To fix this, go to preferences -> Groovy -> Editor. Scroll to the bottom and uncheck the "Dollar slashy strings" checkbox.

Comment by Andrew Eisenberg [ 06/Mar/12 ]

To be clear, this is only in 2.6.1 and later versions of groovy-eclipse.

Comment by N K [ 07/Mar/12 ]

After updating the plugin to the "RELEASE" version i was able to uncheck the option. Now it works fine!





[GRECLIPSE-1392] Organize Imports should remove implicit imports Created: 04/Mar/12  Updated: 06/Mar/12  Resolved: 06/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script:

import java.lang.*
import java.lang.Integer
import java.net.*
import java.net.BindException
import java.util.*
import java.util.List
import groovy.lang.*
import groovy.lang.Binding
import groovy.util.*
import groovy.util.AntBuilder

println Integer
println BindException
println List
println Binding
println AntBuilder

The editor should remove all import statements as they are implicit and not required.

Implicit imports include:

  • java.lang.*
  • java.net.*
  • java.util.*
  • groovy.lang.*
  • groovy.util.*


 Comments   
Comment by Andrew Eisenberg [ 06/Mar/12 ]

Fixed with regression tests.





[GRECLIPSE-1391] Organize Imports does remove blank lines in import group Created: 04/Mar/12  Updated: 06/Mar/12  Resolved: 06/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GRECLIPSE-1390 Organize Imports does not sort by typ... Resolved
Number of attachments : 0

 Description   

In the following script:

import javax.script.Compilable

import javax.script.Bindings

import javax.script.AbstractScriptEngine

println AbstractScriptEngine
println Bindings
println Compilable

Organize Imports does remove blank lines in import group



 Comments   
Comment by Andrew Eisenberg [ 06/Mar/12 ]

Same underlying problem as GRECLIPSE-1390.





[GRECLIPSE-1390] Organize Imports does not sort by type name ascending Created: 04/Mar/12  Updated: 06/Mar/12  Resolved: 06/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GRECLIPSE-1391 Organize Imports does remove blank li... Resolved
Related
relates to GRECLIPSE-1219 Annotations on import statements are ... Resolved
Number of attachments : 0

 Description   

In the following script:

import javax.script.Compilable
import javax.script.Bindings
import javax.script.AbstractScriptEngine

println AbstractScriptEngine
println Bindings
println Compilable

Organize Imports does not sort the import statements by type name ascending.



 Comments   
Comment by Andrew Eisenberg [ 06/Mar/12 ]

Looks like this is a regression that has come from the work on GRECLIPSE-1219.

Comment by Andrew Eisenberg [ 06/Mar/12 ]

Urrrgh...this is going to be messy. In order to ensure that annotations on imports are not removed while still enabled sorting, I must muck around with JDT code so that annotations are remembered for each import statement. When imports are re-organized, the annotations would not be lost.

However, this is a big piece of work. I am leaning towards a simple-half solution:

Before performing the organize, check all import statements for annotations. If they exist, don't reorganize, but just add and remove. If no annotations (the more likely scenario), do a full organize.

This is not the ideal solution, but it is safer, less work, and does not require making the JDT patch any larger.

Comment by Andrew Eisenberg [ 06/Mar/12 ]

Fixed as described in the previous comment. This fix is a reasonable compromise since annotations on imports are fairly rare (usually @Grab), but when they do exist we need to make sure that they are not removed during organize imports.

Comment by Bob Tiernay [ 06/Mar/12 ]

Very reasonable Andrew. I can live with it Thanks





[GRECLIPSE-1389] Invalid unused import warning Created: 04/Mar/12  Updated: 15/Mar/12  Resolved: 15/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Unassigned
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by GRECLIPSE-1408 Unused imports warning only work for ... Open
Number of attachments : 0

 Description   

In the following script

import java.math.BigInteger // Invalid warning here
import java.math.BigDecimal // Invalid warning here

println BigInteger
println BigDecimal

The editor's warning of:

The import java.math.BigDecimal is never used
The import java.math.BigInteger is never used

is invalid



 Comments   
Comment by Andrew Eisenberg [ 15/Mar/12 ]

Looks at GRECLIPSE-1408 for a more complete description of what is happening.





[GRECLIPSE-1388] Content Assist empty for zero length lines Created: 04/Mar/12  Updated: 07/Mar/12  Resolved: 07/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script:

// Ctrl + Space here produces nothing

println "Done"

The line with the comment doesn't produce any content assist proposals. One should see DGM and groovy.lang.Script proposals at that location.



 Comments   
Comment by Andrew Eisenberg [ 07/Mar/12 ]

Fixed. Content assist was getting confused that the completion was happening before the "start" of the script. The start of the script is considered to be the start of the first statement. Making an extra check and things are working now.





[GRECLIPSE-1387] Editor support for Closure properties other than owner and delegate Created: 04/Mar/12  Updated: 20/Apr/12  Resolved: 15/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Editor, Inferencing Engine
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Some other Closure properties are demonstrated below:

def f = { int x -> 
  println thisObject; 
  println resolveStrategy;
  println directive;
  println parameterTypes;
  println maximumNumberOfParameters
}

These should be recoginized in the editor and be available as content assist proposals.



 Comments   
Comment by Andrew Eisenberg [ 15/Mar/12 ]

Fixed. Now, the instance properties (and respective getters) are available through content assist and inferencing.

I didn't add the static properties since I didn't want to bloat the inferencer with things that are rarely used (more precisely...I didn't want to bloat it any more than it already is).

Comment by Bob Tiernay [ 20/Apr/12 ]

Seems as though resolveStrategy still isn't suggested





[GRECLIPSE-1385] An internal error occurred during: "Refresh DSLD scripts" Created: 02/Mar/12  Updated: 31/Aug/12  Resolved: 31/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Major
Reporter: Stevo Slavic Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse IDE 3.7 SR2 EE
JDK 1.7 update 2
m2e 1.0.100
Groovy-Eclipse M2E integration 2.6.0


Number of attachments : 0

 Description   

On importing existing Maven projects, out of which some use groovy, error dialog gets shown:

An internal error occurred during: "Refresh DSLD scripts"

Also in eclipse log file following entry appears:

!ENTRY org.eclipse.core.jobs 4 2 2012-03-02 09:18:13.468
!MESSAGE An internal error occurred during: "Refresh DSLD scripts".
!STACK 0
BUG! exception in phase 'semantic analysis' in source unit 'DSLD_meta_script.dsld' Argument "clazz" must not be null!
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:929)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:594)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:543)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:267)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:214)
	at org.codehaus.groovy.eclipse.dsl.script.DSLDScriptExecutor.executeScript(DSLDScriptExecutor.java:240)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.refreshProject(RefreshDSLDJob.java:295)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:227)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.IllegalArgumentException: Argument "clazz" must not be null!
	at org.eclipse.equinox.weaving.internal.caching.BundleCachingService.storeClass(Unknown Source)
	at org.eclipse.equinox.weaving.adaptors.WeavingAdaptor.storeClass(Unknown Source)
	at org.eclipse.equinox.weaving.hooks.WeavingHook.recordClassDefine(Unknown Source)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:614)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:562)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:486)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:459)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400)
	at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:473)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:410)
	at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:696)
	at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:564)
	at org.codehaus.groovy.control.ResolveVisitor.resolveToClass(ResolveVisitor.java:842)
	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:364)
	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:316)
	at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:1014)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:877)
	at org.codehaus.groovy.ast.expr.MapEntryExpression.transformExpression(MapEntryExpression.java:41)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:892)
	at org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:63)
	at org.codehaus.groovy.ast.expr.NamedArgumentListExpression.transformExpression(NamedArgumentListExpression.java:36)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:892)
	at org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:49)
	at org.codehaus.groovy.ast.expr.TupleExpression.transformExpression(TupleExpression.java:82)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:892)
	at org.codehaus.groovy.control.ResolveVisitor.transformMethodCallExpression(ResolveVisitor.java:1222)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:883)
	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1505)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.control.ResolveVisitor.transformClosureExpression(ResolveVisitor.java:1201)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:885)
	at org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:49)
	at org.codehaus.groovy.ast.expr.ArgumentListExpression.transformExpression(ArgumentListExpression.java:67)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:892)
	at org.codehaus.groovy.control.ResolveVisitor.transformMethodCallExpression(ResolveVisitor.java:1222)
	at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:883)
	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1505)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:50)
	at org.codehaus.groovy.control.ResolveVisitor.visitConstructorOrMethod(ResolveVisitor.java:225)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1172)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1440)
	at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:200)
	at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:659)
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:920)
	... 10 more


 Comments   
Comment by Andrew Eisenberg [ 02/Mar/12 ]

To get a little more context here:

  1. Is this problem repeatable?
  2. Do you see any behaviors not working for you?
  3. If you go to Preferences -> Groovy -> DSLD and click "Recompile Scripts", does the problem happen again?

Also, if this is reproducible, any chance I can get a hold of the maven project that causes this?

Comment by Andrew Eisenberg [ 02/Mar/12 ]

Here is what is going on: This problem is happening while compiling a DSLD script. The DSLD script is compiled using a classloadeer that is a child of an Eclipse (OSGi) classloader. You have equinox weaving installed in your Eclipse (a part of AJDT). Equinox weaving is attempting to cache the woven class after it has been loaded, but is getting an error there.

However, equinox weaving has no business trying to touch the DSLD class since it is not an aspect class, nor will it have any aspects applied to it. Rather, it should be ignored by equinox weaving.

Comment by Andrew Eisenberg [ 06/Mar/12 ]

Raised an equinox weaving bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=373397

Comment by Andrew Eisenberg [ 06/Mar/12 ]

Will ask to get it fixed for 2.7.0.

Comment by Stevo Slavic [ 06/Mar/12 ]

Great, thanks! Just voted there.

Comment by Andy Clement [ 07/Mar/12 ]

As mentioned in the other bug - it is possible the Java7 verification strictness is a factor here. To see if it makes any difference you could try running with the older verifier strategy by starting the JVM with this option:

-XX:-UseSplitVerifier

I think you'll need to put it in the vmargs section in the sts.ini (or eclipse.ini) file.

Comment by Stevo Slavic [ 08/Mar/12 ]

Configuring UseSplitVerifier did the trick. Thanks!

Comment by Stevo Slavic [ 08/Mar/12 ]

Unfortunately now other things started breaking, e.g. here is stacktrace:

!ENTRY org.eclipse.core.jobs 4 2 2012-03-08 11:30:36.873
!MESSAGE An internal error occurred during: "Initialize Java Debug Options".
!STACK 0
java.lang.IllegalArgumentException: Argument "clazz" must not be null!
	at org.eclipse.equinox.weaving.internal.caching.BundleCachingService.storeClass(Unknown Source)
	at org.eclipse.equinox.weaving.adaptors.WeavingAdaptor.storeClass(Unknown Source)
	at org.eclipse.equinox.weaving.hooks.WeavingHook.recordClassDefine(Unknown Source)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:614)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:562)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:486)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:459)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:476)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at org.eclipse.jdt.debug.core.JDIDebugModel.createExceptionBreakpoint(JDIDebugModel.java:437)
	at org.eclipse.jdt.internal.debug.ui.JavaDebugOptionsManager$InitJob.run(JavaDebugOptionsManager.java:153)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

"Argument "clazz" must not be null!" error also appeared when just opening type in editor.

Comment by Andrew Eisenberg [ 31/Aug/12 ]

The fix for this is now in Equinox 3.8 (available in the e42 branch of groovy-eclipse). I am resolving this bug. If you still see it in e42, then something else is going on and please raise a new issue.





[GRECLIPSE-1382] Editor does not infer types on default method parameter values Created: 01/Mar/12  Updated: 05/Jun/14  Resolved: 05/Jun/14

Status: Closed
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Unassigned
Resolution: Not A Bug  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script:

def f(x = 0) {
    x.intValue()   
}

The editor does not infer that the type of x is

{Integer}

and is underlined



 Comments   
Comment by Denis Murashev [ 05/Jun/14 ]

This is not the case where parameter type inference should be implemented.
For example, the method above can be called with String argument.

f("1")

And it will cause runtime exception.

Comment by Denis Murashev [ 05/Jun/14 ]

Works as Designed





[GRECLIPSE-1379] Warning after backspace after content assist for parenthesized expressions Created: 29/Feb/12  Updated: 22/Apr/13  Resolved: 22/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script:

(1). // Wait for proposals, then press delete
println "done"

After waiting for the proposal list after typing

{(1).}

followed by pressing

{backspace}

, the "Problems During Content Assist" alert box is presented:

 
The 'Groovy Code Completions' proposal computer from the 'org.codehaus.groovy.eclipse.codeassist.completion' plug-in did not complete normally. The extension has thrown a runtime exception.

The following entry is then added to the "Error Log":

java.lang.NullPointerException
	at org.codehaus.groovy.eclipse.codeassist.creators.MethodProposalCreator.getAllMethods(MethodProposalCreator.java:114)
	at org.codehaus.groovy.eclipse.codeassist.creators.MethodProposalCreator.findAllProposals(MethodProposalCreator.java:58)
	at org.codehaus.groovy.eclipse.codeassist.processors.StatementAndExpressionCompletionProcessor.proposalCreatorLoop(StatementAndExpressionCompletionProcessor.java:469)
	at org.codehaus.groovy.eclipse.codeassist.processors.StatementAndExpressionCompletionProcessor.generateProposals(StatementAndExpressionCompletionProcessor.java:355)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.computeCompletionProposals(GroovyCompletionProposalComputer.java:161)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:318)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:267)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:283)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:243)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1830)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1435)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1424)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:372)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3563)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3212)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)


 Comments   
Comment by Andrew Eisenberg [ 22/Apr/13 ]

Fixed. Added a guard to ensure this exception is avoided.





[GRECLIPSE-1378] Support for Groovy 2.0 Created: 29/Feb/12  Updated: 16/May/12  Resolved: 16/May/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution, Compiler Integration
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This issue will cover all the work we need to do for supporting groovy 2.0.

Here are the different pieces:

  1. The compiler patch
  2. Updating the project structure and CI build
  3. Ensure unit tests run against 2.0 as well as 1.8
  4. Provide UI support for compiler switching
  5. test that command line switching of the compiler is working


 Comments   
Comment by Andrew Eisenberg [ 05/Mar/12 ]

Just committed the initial bundle and feature for 2.0. This is currently a copy of the 1.8.x bundle and feature.

Comment by Andy Clement [ 19/Apr/12 ]

(1) Dev builds now contain Groovy 2.0 based on a 2.0 snapshot from last week.

(4) Rudimentary UI for compiler switching is in place.

(5) Haven't tested

Comment by Andrew Eisenberg [ 16/May/12 ]

This is now available in snapshot releasess.





[GRECLIPSE-1375] Invalid source location for typed closure argument as Open Declaration target Created: 27/Feb/12  Updated: 28/Feb/12  Resolved: 28/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following code:

Closure c = { int i ->
    println i // Press F3 while selecting or CTRL+Clicking on i
}

Pressing F3 or CTRL+Click ing on i navigates to and selects the 'i' in int and not the variable name i.



 Comments   
Comment by Andrew Eisenberg [ 28/Feb/12 ]

Simple fix. Will make it into 2.6.1.





[GRECLIPSE-1374] Inconsistent content assist for parenthesized expressions Created: 27/Feb/12  Updated: 29/Feb/12  Resolved: 29/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to GRECLIPSE-1377 Inconsistent completions for parenthe... Open
Number of attachments : 0

 Description   

The following expression produces String proposals in the editor:

('').toUpperCase() // ('').t<CTRL+Space> produces toUpperCase

However, the following does not produce Integer proposals:

(1).intValue() // (1).i<CTRL+Space> does not produce intValue

Also interesting to note is that even in the first case toUpperCase isn't suggested with zero characters following the '.'



 Comments   
Comment by Andrew Eisenberg [ 28/Feb/12 ]

Problem here is with source locations. The content assist processor is completing against an offset corresponding to after the close paren, but the source location of the ASTNode inside of the parens has an end position that is inside of the parens.

So, the processor should find the AST node inside of the parens, but doesn't and so completes against Object or String.

Comment by Andrew Eisenberg [ 29/Feb/12 ]

Mostly fixed.

Still not working if content assist comes at the end of the file with no prefix. Eg-

(1).

If the '.' marls the end of the file, then the target of the completion will be the script. Otherwise if there is text after the dot, then things will be completed as expected.

Comment by Andrew Eisenberg [ 29/Feb/12 ]

Resolving this issue and raising GRECLIPSE-1377 for the remaining work.





[GRECLIPSE-1373] Extract local variable causes unstable display of code in Eclipse Indigo SR1 Created: 26/Feb/12  Updated: 14/Jan/14  Resolved: 18/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.7.1.Release

Type: Bug Priority: Minor
Reporter: Tim Bain Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Indigo SR1, Windows XP SP3


Number of attachments : 0

 Description   

When I perform an extract local variable refactoring action on a Groovy class within my Grails app, the refactoring works (if I close the file and re-open it, the variable is present in the code and has the right code snippet assigned to it), but if I don't close the file, the display of the file within Eclipse appears to transition back and forth between the original version and the refactored version. The changes seem to happen when I scroll (which seems to only affect lines that are exiting/entering the screen) or click on different lines (which affects the lines I'm coming from and going to, but sometimes also other lines) and maybe also when I mouse-over on a variable or method. I haven't figured out a pattern for when it shows the original version of a line and when it shows the new version.

This incorrect and unstable view will continue until I either close and re-open the file (in which case the display is fully normal with the refactored code visible) or undo the refactoring (which immediately eliminates the instability).



 Comments   
Comment by Andrew Eisenberg [ 07/Mar/12 ]

This is just so strange...

This does sound more like an SWT problem and is therefore likely OS dependent. I can't reproduce this locally, but I will look for open SWT bugs to see if any match your description.

Comment by Andrew Eisenberg [ 07/Mar/12 ]

And some more questions...

  1. Are you using dual monitors or an external monitor?
  2. Any errors in the error log?
Comment by Tim Bain [ 11/Mar/12 ]

Nope, nothing in the error log.

I'm using a single monitor. I'm not sure what you mean by "an external monitor", unless you wondered whether I had a monitor plugged into a laptop (but I'm using a desktop, so that doesn't apply). But this doesn't seem like a monitor issue; the monitor works perfectly fine for everything else I do in Eclipse (and outside), and the same lines are rendered to the screen fine when I close and re-open the file. It's pretty clearly something going on within Eclipse, not outside of it.

I also just noticed: when the rendering is incorrect, it seems not to be displaying (or acknowledging the existence of) the final character in the line that was just created. (That is, if I extract the integer literal 2012 into a local variable called year, the resulting text that is displayed on the screen is: def year = 201, and when I use the mouse to move to the end of that line, the 1 appears to be the final character.) But if I save the file and then close and re-open it, the 2 is indeed saved.

Also, I didn't mention it in my description, but if I scroll such that one of the affected lines is only partially on the screen and then scroll so that the entire line is on the screen, I'll see a split-line view, where the part of the line that never went off-screen shows the version of the line that was on the screen originally, but the part that went off-screen shows a different line of text (which is what I'd see if I switch to a different application and switched back, forcing a screen refresh). That may or may not be relevant (it may simply be an optimization Eclipse has done, which would work fine if the lines were drawing right but doesn't work when this other error is occurring), but maybe it'll be useful in finding an explanation.

Comment by Andrew Eisenberg [ 11/Mar/12 ]

I didn't mean to imply that there might be something physically wrong with your monitor. The reason why I asked is that I have heard of redraw errors in the editor when using an external display (eg- a monitor hooked up to a laptop).

As I said, this looks like an SWT bug (SWT is the UI toolkit for Eclipse) and not an OS bug. I had a good look for similar bugs on bugzilla, but haven't found anything yet.

I'll try posting on the SWT forums.

Comment by Andrew Eisenberg [ 18/Jul/12 ]

Closing this issue since we are no longer directly supporting indigo. If this problem still happens on juno (Eclipse 4.2), please reopen or comment here.

I have not heard any response from the swt team, nor have I been able to reproduce this myself.

Comment by Andre Steingress [ 21/Dec/12 ]

I am having the same issue here with Windows 7 and Eclipse 4.2:

Version: 3.1.0.RELEASE
Build Id: 201210061306
Version: 2.7.1.xx-20120921-2000-e42RELEASE

No external monitor.

Comment by Andrew Eisenberg [ 21/Dec/12 ]

Is this fully reproducible? Can you send over a file where this happens to you?

Comment by Andre Steingress [ 21/Dec/12 ]

First I thought it occurs in more complex situations and I tried to separate the problem. But in the end , the issue occurred with a class as simple as:

 

class ExtractLocalVariableTests {

    void testExtraction() {
        1 + 1
    }
}

When I try to extract the 1 + 1 expression into variable i and afterwards move the cursor, the behaviour is as described above.

Comment by Andrew Eisenberg [ 21/Dec/12 ]

Thanks for the sample. Can't reproduce on mac. Will fire up a windows vm and try there.

Comment by Andrew Eisenberg [ 21/Dec/12 ]

Wow. I see it now on windows.

Comment by Andre Steingress [ 21/Dec/12 ]

Glad you were able to reproduce it. can you see any indication for this behaviour?

Comment by Tony Erskine [ 14/Jan/14 ]

This issue still exists in eclipse 4.2 (GGTS 3.4) on windows 7 & 8. Is there another issue that is tracking it for the newer versions?

This does not happen on my Linux boxes.





[GRECLIPSE-1372] Maven test classes are visible to WTP Created: 18/Feb/12  Updated: 07/Mar/12  Resolved: 07/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Steve Skrla Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: classpath, maven, test, wtp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mint Linux, J2EE Eclipse Package (Indigo-SR1), WTP w/ Tomcat 6


Attachments: GZip Archive wtp-classpath-project.tar.gz    
Number of attachments : 1

 Description   

When scanning the classpath an application being served by WTP will be able to see resources found in src/test/groovy and src/test/java. This is inconsistent with how M2E and WTP behave without groovy eclipse.

See attached project:
What happens
.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/ContextListener.class
.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/GroovyClass.class
.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/JavaTestClass.class
.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/GroovyTestClass.class

What is expected (disable the build portion of the pom to see the following result):
.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/ContextListener.class

I should also note that the same holds true for test resources from other projects in the workspace that the current project depends on.



 Comments   
Comment by Steve Skrla [ 18/Feb/12 ]

Sorry, .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/GroovyClass.class should also be in the "What is expected" section.

Comment by Andrew Eisenberg [ 18/Feb/12 ]

Interesting. I don't know anything about how wtp determines what folders should be part of the deployed application. I'll have to have a deeper look. Any suggestions on where to look would be appreciated.

Comment by Steve Skrla [ 19/Feb/12 ]

Unfortunately I don't have the first clue =(

Comment by Andrew Eisenberg [ 20/Feb/12 ]

I had a look at your project, and didn't see anything odd immediately. However, never having used WTP or WTP integration for maven, I'll need you to be a bit more specific on how to reproduce the problem:

  1. How do you get to the point that the classpath gets to be scanned?
  2. Are you running the project on a server? Which one?
  3. How do you deploy the app? How are you building the app?
  4. Is the problem only with debugging, or does the deployed app also contain the extra directories?
Comment by Steve Skrla [ 20/Feb/12 ]

I am using the excellent Reflections library both in my actual project, and the test. It performs as expected when I disable the groovy compiler plugin, so I am fairly certain the problem does not lie there.

  1. From the market place, install the WTP M2E plugin.
  2. Load the project, right click the project entry and select Run As... > Run on Server...
  3. Follow the steps to setup a Tomcat 6.x server (you may want to download it separately and point the plugin to it, the automated installation can be less then helpful). The default installation should be fine, WTP will configure everything else for you
  4. Add the project to the server when prompted.
  5. At this point it should try to start the server and you will get a bunch of logging information from tomcat. It should print out the lines:
        .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/ContextListener.class
        .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/GroovyClass.class
        .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/JavaTestClass.class
        .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/bug-wtp-test-classpath/WEB-INF/classes/com/groovyeclipse/bug/wtpclasspath/GroovyTestClass.class
    

What it should print out is only ContextListener.class and GroovyClass.class

I have not tested mvn package from the command line (responding from home atm), but if it is ALSO doing this then both the compiler and the project configurator have issues.

Comment by Andrew Eisenberg [ 07/Mar/12 ]

I had a discussion on the wtp mailing list. Looks like there is an easy workaround for this:

Open the project preferences -> Deployment Assembly

Remove all the test folders that should not be deployed. This should work.

However, it may be that running Update configuration on the project and the folders will come back again, so just be careful. I will likely submit a patch to the wtp project so that the test folders are automatically removed if they are found.

Comment by Andrew Eisenberg [ 07/Mar/12 ]

See the mailing list thread here:
http://dev.eclipse.org/mhonarc/lists/m2e-users/msg02331.html

Looks like upgrading to 0.15.0 of WTP will get this working for you.





[GRECLIPSE-1371] Expression referencing static import in static field initializer produces error Created: 16/Feb/12  Updated: 20/Feb/12  Resolved: 20/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Editor
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following script:

import static Boolean.TRUE

class StaticImportStaticField {
    static staticField = TRUE // Error: 'T'RUE is underlined
}

produces the following error in the editor:

Groovy:Apparent variable 'TRUE' was found in a static scope but doesn't refer to a local variable, static field or class. Possible causes:

However, this error does not show up in the "Problems" view.



 Comments   
Comment by Andrew Eisenberg [ 16/Feb/12 ]

Looks like this is a problem with the reconciler. It may have something to do with how we disable certain visitors during a reconcile that are around during a compile.

Comment by Bob Tiernay [ 17/Feb/12 ]

I should note that this is something that was introduced in the last couple of weeks. I just noticed it on an old source file. Perhaps this has something to do with the enhanced static import support that was added recently?

Comment by Andrew Eisenberg [ 17/Feb/12 ]

That was my suspicion, that this is a regression due to the changes, We had to make a change to one of the compilation phases, and it looks like it has this side effect.

Comment by Andrew Eisenberg [ 17/Feb/12 ]

Confirmed that this problem was caused by the changes I introduced in GRECLIPSE-1363.

In that issue, I disabled/enabled the StaticImportVisitor from running depending on whether it was or was not running during a reconcile (ie- in the editor vs a compile).

Looks like we need a bit of a more fine-grained control over how the visitor runs.

Comment by Andrew Eisenberg [ 20/Feb/12 ]

Here is what the problem is:

  1. In a static context, references to fields and methods must be statically available
  2. The StaticImportsVisitor esures the mapping from a staticly imported reference is correctly mapped
  3. Disabling the StaticImportsVisitor will mean that these kinds of references cannot be statically determined. This is why you were seeing the error.
  4. However, enabling the visitor, caused (one of) the problem(s) described in GRECLIPSE-1363. More specifically, the reference was converted to a StaticMethodCallExpression. It is converted into a getter reference for the property. This messes with source locations and means that the name of the AST node does not match the underlying text. And this causes all sorts of problems with inferencing, navigation, searching, etc.

The solution is (for reconciling only) to convert to a PropertyExpression instead of a StaticMethodCallExpression. It looks like everything works out this way.

Thanks for reporting this bug. There may be others in this area since I am not entirely familiar with exactly what the StaticImportsVisitor does.

Comment by Andrew Eisenberg [ 20/Feb/12 ]

I committed the fix and I am resolving this bug.





[GRECLIPSE-1370] Add project level warning / error when groovy library on classpath does not match compiler version Created: 14/Feb/12  Updated: 16/Jul/12  Resolved: 16/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.7.1.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Users who manage their groovy dependency via maven, a project jar, etc. will run into issues when the version of the groovy library used with greclipse does not match. This can lead to confusing situations at runtime. This has happened several times to me personally across several groovy projects and team members.

There should be a warning / error issued when greclipse determines that the classpath groovy version does not "match" that of the plugin (perhaps by comparing groovy.lang.GroovySystem.getVersion() values).



 Comments   
Comment by Bob Tiernay [ 14/Feb/12 ]

This situation can arise when

  • greclipse is updated
  • greclipse compiler switching occurs
  • pom.xml:org.codehaus.groovy:groovy-all or ./lib/groovy-all.jar is updated
Comment by Andrew Eisenberg [ 07/Mar/12 ]

This is a very useful feature and should be available somehow. However, there are 2 pieces that are unclear to me how to implement:

  1. What is the safest and fastest way to determine which version of groovy is on the classpath? In the end probably the entire classpath must be scanned for something that looks like a groovy jar, which could be time consuming. So, this leads to...
  2. When should this check happen? If it happens too often, then that would be annoying for users. If not often enough, then genuine problems could be missed.

At a minimum, the compiler needs to be checked in these situations:

  • Whenever a groovy project classpath changes
  • Whenever a groovy project is created, imported, or opened
  • Whenever the workspace compiler changes (this is quite tricky to check correctly since the compiler level can only change on restart and lots of things can happen to change it). I may wind up having to check on eevery restart, but this could lead to an even slower startup time.
Comment by Bob Tiernay [ 07/Mar/12 ]

I'm totally ignorant to anything jdt or eclipse, but is there an event that jdt publishes when the classpath is changed? If multiple classes exist on the classpath, is this visible in the jdt api?

Is this relevalent? http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/IJavaProject.html

Is groovy.lang.GroovySystem.getVersion not reliable?

Another idea comes from the java world. A java project has the notion of a "JDK Compliance" based on an "Execution Environment" perhaps GRECLIPSE could have a similar feature and could do things such as produce errors when conflicts occur, etc.

Comment by Andrew Eisenberg [ 16/Jul/12 ]

I implemented this feature. Now, there is a project property added to each project that defines which Groovy compiler level is expected.

This commit includes:

  • A compilation participant for creating and removing markers
  • marker resolutions for providing quick fixes to deal with markers
  • a workspace preference that can disable the behavior
  • changes to workspace and project compiler preference pages to provide UI support for managing.

Full commit is available here:
https://github.com/groovy/groovy-eclipse/commit/a4ea7bd5ade078c4a4877a09c24571acba5c23b1





[GRECLIPSE-1369] Java search for references to getter returns references to corresponding field Created: 08/Feb/12  Updated: 09/Feb/12  Resolved: 08/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Search
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Critical
Reporter: Hannes Schmidt Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Open a project with Groovy nature, open a Java source file, right-click a getter method, say, getFoo(), click References - Workspace.

Actual: The search view lists references to the method getFoo() as well as references to the corresponding field foo.

Expected: Only references to the actual method should be listed. References to the field should not be listed.

Workaround: Remove Groovy nature from project and repeat search. Search will revert to expected behavior.

I believe this has to do with the plugin now being able to search for synthetic accessors. But this is a Java file and the plugin should stay the heck out of that.



 Comments   
Comment by Andrew Eisenberg [ 08/Feb/12 ]

That shouldn't be.

Comment by Andrew Eisenberg [ 08/Feb/12 ]

A little more clarification. Here is what we need to ensure:

Scenario 1:

Groovy:
class G {
  int yyy
}

Java: 
class J {
  void meth() {
    new G().getYyy();
    new G().yyy = 0;  // an error, but still refers to the field in G
  }
}

Reference to getYyy and yyy should be resolved to the declaration.

Scenario 2:

Groovy:
class G {
  public int yyy
}

Java: 
class J {
  void meth() {
    new G().getYyy();  // an error, but still refers to the field in G
    new G().yyy = 0;
  }
}

Same. Reference to getYyy and yyy should be resolved to the declaration.

Scenario 3:

Groovy:
new J().nuthin
new J().getNuthin()

Java: 
class J {
  public int getNuthin() {return 0;}
}

Reference to getNuthin and nuthin should be resolved to the declaration.

Scenario 4:

Groovy:
new J().nuthin
new J().getNuthin()

Java: 
class J {
  public int nuthin;
}

Reference to nuthin is resolved but getNuthin is not.

Scenario 5:

Groovy:
empty

Java: 
class J {
  public int nuthin;
  void foo() {
    new J().nuthin
    new J().getNuthin()
  }

Reference to nuthin is resolved but getNuthin is not.

Comment by Andrew Eisenberg [ 08/Feb/12 ]

To be clear, the problem described in this bug is that scenario 3 is matching in Java, but it should only be matching in Groovy.

Comment by Andrew Eisenberg [ 08/Feb/12 ]

Fix is committed with regression tests.

Comment by Hannes Schmidt [ 09/Feb/12 ]

That was fast. Very cool, thanks!

Comment by Andrew Eisenberg [ 09/Feb/12 ]

I raised the priority to critical because Groovy-Eclipse should not be affecting the results of pure Java code. However, the fix is not available in a dev build yet since we are having test failures on the build server.

Comment by Andrew Eisenberg [ 09/Feb/12 ]

I raised the priority to critical because Groovy-Eclipse should not be affecting the results of pure Java code. However, the fix is not available in a dev build yet since we are having test failures on the build server.





[GRECLIPSE-1368] Log entries claiming "error in opening zip file" accessing dsld support related folders Created: 08/Feb/12  Updated: 22/Feb/12  Resolved: 21/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Minor
Reporter: Davide Cavestro Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy-Eclipse 2.6.1.xx-20120118-1100-e37-M1
on
SpringSource Tool Suite - Version: 2.9.0.M2 - Build Id: 201201191000 (upgraded from 2.8.1)


Number of attachments : 0

 Description   

I've noticed some errors on my workspaces logs, such as:

!ENTRY org.eclipse.jst.jsp.core 2 2 2012-02-07 18:04:47.686
!MESSAGE Taglib Index ZipException: /home/davide/.groovy/greclipse/global_dsld_support error in opening zip file

!ENTRY org.eclipse.jst.jsp.core 2 2 2012-02-07 18:04:47.687
!MESSAGE Taglib Index ZipException: /home/davide/opt/springsource/sts-2.8.1.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20120118-1100-e37-M1/plugin_dsld_support/ error in opening zip file

The strange thing is that they refer to folders (and not to compressed archives), as you can see:

davide@ws-davide:~$ ls -la /home/davide/.groovy/greclipse/global_dsld_support /home/davide/opt/springsource/sts-2.8.1.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20120118-1100-e37-M1/plugin_dsld_support/
/home/davide/.groovy/greclipse/global_dsld_support:
total 8
drwxr-xr-x 2 davide davide 4096 Dec 13 18:35 .
drwxr-xr-x 3 davide davide 4096 Dec 13 18:35 ..

/home/davide/opt/springsource/sts-2.8.1.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20120118-1100-e37-M1/plugin_dsld_support/:
total 16
drwxr-xr-x 3 davide davide 4096 Feb  1 09:18 .
drwxr-xr-x 7 davide davide 4096 Feb  1 09:18 ..
drwxr-xr-x 2 davide davide 4096 Feb  1 09:18 dsld
-rw-r--r-- 1 davide davide  331 Jan 18 13:27 readme.txt



 Comments   
Comment by Andrew Eisenberg [ 08/Feb/12 ]

Interesting...

Some questions:

  1. Do you have any stack traces for this? They might be included with the log entry.
  2. Do you know which project this is happening in? Is it a grails project? Or a Groovy project that uses JSPs in some way?
  3. Are you on Linux?
  4. Other than the stack trace, is this causing any noticeable problems?
  5. How often are the entries coming? Do you know what causes the exceptions to occur?
Comment by Davide Cavestro [ 08/Feb/12 ]

1. Do you have any stack traces for this? They might be included with the log entry.

No, my log only contains the message I sent to you.

2. Do you know which project this is happening in? Is it a grails project? Or a Groovy project that uses JSPs in some way?

It's a gradle multiproject with some web applications (war overlay simulation).

3. Are you on Linux?

Yes, Debian GNU/Linux 6.0

Other than the stack trace, is this causing any noticeable problems?

Not at all

How often are the entries coming? Do you know what causes the exceptions to occur?

It happens only once or twice per day... but I don't know the cause.

Comment by Andrew Eisenberg [ 08/Feb/12 ]

I'm guessing that the problem is coming around because of an interaction with WTP and the Groovy DSL classpath containers. Do you have any groovy code in your gradle projects (besides the build files themselves)? If not, I'd recommend removing the Groovy DSL classpath container from your build path(s).

Comment by Davide Cavestro [ 09/Feb/12 ]

Some projects of the multi-project build contains several groovy files (they apply the groovy plugin)... so the question is: what happens if I remove Groovy DSL Support from their Java Build Path?
By the way it is interesting to notice that Groovy DSL Support is also enabled as an exported entry (I really didn't mean that).
Could it be the cause of such interaction with WTP and the Groovy DSL classpath containers?
I could also try to see if removing the export checkbox from Groovy DSL Support the error message still appears.

Comment by Andrew Eisenberg [ 09/Feb/12 ]

That's a good point about exporting the classpath container. It shouldn't be. I changed the code so that the DSL Support container will not be exported by default.

Let mw know if disabling export fixes the problem.

Comment by Mauro Molinari [ 17/Feb/12 ]

Today I reproduced the problem myself with GRECLIPSE 2.6.1.xx-20120118-1100-e37-M1.
I know it does not contain your latest change, but I'm quite sceptical the problem may reside in the fact that the DSL Support container is exported.
The log entries produced in my case are:

!ENTRY org.eclipse.jst.jsp.core 2 2 2012-02-17 10:02:00.179
!MESSAGE Taglib Index IOException: C:/Users/mauro/.groovy/greclipse/global_dsld_support C:\Users\mauro\.groovy\greclipse\global_dsld_support (Accesso negato)

!ENTRY org.eclipse.jst.jsp.core 2 2 2012-02-17 10:02:00.180
!MESSAGE Taglib Index IOException: D:/Eclipse37/plugins/org.codehaus.groovy_1.8.4.xx-20120118-1100-e37-M1/plugin_dsld_support/ D:\Eclipse37\plugins\org.codehaus.groovy_1.8.4.xx-20120118-1100-e37-M1\plugin_dsld_support (Accesso negato)

I'm pretty sure they were produced while the validation of the JSPs of my Dynamic Web Project was running.
The "export" flag of build path entries have nothing to do with Dynamic Web Project processing or JSP validation, this is why I don't think that is the source of the problem.

Isn't the fact that org.eclipse.jst.jsp.core is looking at the greclipse settings directory in my system home directory a clue of something?

Comment by Andrew Eisenberg [ 21/Feb/12 ]

Thanks Mauro. Finally got a chance to look at this. It seems that I can reproduce the problem by having at least one jsp file in a Dynamic Web project. But I can only get the errors to occur at startup.

Comment by Andrew Eisenberg [ 21/Feb/12 ]

This is a WTP bug. I raised this issue, which describes the full problem and how to reproduce without groovy-eclipse:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=372180

Feel free to comment on it if you would like the team to notice it faster.

Comment by Andrew Eisenberg [ 21/Feb/12 ]

Closing as won't fix since the root cause is not in groovy-eclipse.

Comment by Mauro Molinari [ 22/Feb/12 ]

Thank you Andrew, I will certainly follow the bug report.





[GRECLIPSE-1366] Make "Enable script folder support" a project level configuration Created: 03/Feb/12  Updated: 10/Feb/12  Resolved: 10/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Project Settings
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Minor
Reporter: Robert Winch Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It would be nice to make Groovy->Compiler->Enable Script Folders configuration to be a project specific configuration. This would allow plugins like the Gradle Eclipse to manage this configuration.



 Comments   
Comment by Robert Winch [ 03/Feb/12 ]

See also https://issuetracker.springsource.com/browse/STS-2426 and http://forum.springsource.org/showthread.php?122732-Gradle-Tooling-and-Setting-Groovy-Script-Folders

Comment by Kris De Volder [ 03/Feb/12 ]

Note: In order for a gradle build script to be able to access / modify the setting it should be stored in the project itself (e.g. like other Eclipse project preferences stored in files under $

{projectDir}

/.settings)

Comment by Andrew Eisenberg [ 03/Feb/12 ]

This request makes sense. In fact, it was always the intention to make script folder settings a per-project setting, but we wanted to wait until a user requested it before spending the time to implement.

Comment by Bob Tiernay [ 03/Feb/12 ]

Would it also make sense to be able to configure the compiler at the project level? We have been bitten by this when some developers don't upgrade their greclipse version / compiler setting. It would be nice if there was a way to integrate this with maven as well. Sorry if this isn't the right place to ask this question

Comment by Andrew Eisenberg [ 03/Feb/12 ]

In theory, yes. It would be nice to have a project-specific compiler setting, but this is not as easy as it sounds since we would need to be able to use different classloaders for each project based on local settings. This in turn requires that there is a standard API that we can use to call multiple versions of the compiler. And this further requires that we implement some OSGi magic to handle the fact that there will be more than one instance of the groovy bundle loaded. And, lastly, this requires that we be very careful not to accidentally refer to classes from the wrong compiler level in a project.

This is all possible, but a big deal of work and something that is unrelated to this bug report.

Comment by Andrew Eisenberg [ 10/Feb/12 ]

I now committed this and it will be available in the next dev build. Please let me know if you get a chance to try it.





[GRECLIPSE-1364] Convert to static import Created: 30/Jan/12  Updated: 30/Jan/12  Resolved: 30/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist, Refactoring
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.6.1.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Should be able to convert a static reference to a static import. Eg-

...stuff

MyClass.CONSTANT

Should become

import static foo.bar.MyClass.CONSTANT

...stuff

CONSTANT


 Comments   
Comment by Bob Tiernay [ 30/Jan/12 ]

Not sure, but this looks like a duplicate of https://jira.codehaus.org/browse/GRECLIPSE-1130. Recommend closing one.

Comment by Andrew Eisenberg [ 30/Jan/12 ]

Close enough. I'll close this one. GRECLIPSE-1130 was mis-categorized, so I didn't see it. I'll comment on the other bug.





[GRECLIPSE-1363] Code select and search not working for static imports Created: 30/Jan/12  Updated: 31/Jan/12  Resolved: 31/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Search
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using the example in GRECLIPSE-1359, searching for references to FOO yields empty search results. There is clearly lots of work that needs to be done for static imports.



 Comments   
Comment by Andrew Eisenberg [ 30/Jan/12 ]

The problem has several pieces. First, StaticImportsVisitor was visiting the entire file and mucking around with references to static imports. Depending on the situation, they were inlined, changed to static method calls, or otherwise made incomprehensible to the editor. Second, the source locations of import nodes themselves do not store the source location for the import node field.

I made two changes:

  1. ensure that the StaticImportsVisitor does not run for reconciles
  2. add 2 fields to ImportNode a constant expression for the field name, and another for the alias (not used yet, see GRECLIPSE-1364).
  3. ensure that these new AST nodes are properly visited during inferencing.

Doing so ensures proper inferencing, mark occurrences, and searching occurs and will fix a number of open bugs.

This change has affected Groovy-core, so this should be backported to Groovy 1.7. And test cases still need to be created.

Comment by Andrew Eisenberg [ 31/Jan/12 ]

Fixed with regression tests.





[GRECLIPSE-1362] Auto-prune Groovy-Eclipse snapshots directory on S3 Created: 30/Jan/12  Updated: 30/Jan/12  Resolved: 30/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.6.1.Release

Type: Task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, the S3 repository that holds Groovy-Eclipse snapshots (the update site that STS points to) is not auto-pruned and we have lots of old artifacts that we don't need. We should be removing old zips as we update new ones.



 Comments   
Comment by Andrew Eisenberg [ 30/Jan/12 ]

After having a bit of a look into this, I will not do any auto-pruning, manual pruning is very straight forward. I'll just make sure I delete all old zips when I upload a new one. This way I get more control over what I delete and when, and I also don't have to spend time creating a script to do this for me.





[GRECLIPSE-1361] Provide Eclipse 4.2 based jdt.core patch Created: 30/Jan/12  Updated: 21/Feb/12  Resolved: 21/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 21/Feb/12 ]

Now available. Just waiting for the build server to be working and we will start releasing snapshots.





[GRECLIPSE-1359] Rename class refactoring doesn't modify static imports Created: 30/Jan/12  Updated: 31/Jan/12  Resolved: 31/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Number of attachments : 0

 Description   

In TestClass.groovy:

class TestClass {
   static int FOO = 1
}

in Test.groovy:

import static TestClass.FOO

TestClass tc = new TestClass() // Rename class here

If one performs the rename class refactoring in Test.groovy by selecting the TestClass token, the import static TestClass.FOO expression is unaffected



 Comments   
Comment by Andrew Eisenberg [ 31/Jan/12 ]

Fixed with regression tests.





[GRECLIPSE-1358] Content assist proposals and type inferencing for private memebers Created: 29/Jan/12  Updated: 21/Feb/12  Resolved: 21/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Inferencing Engine
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: 2.0_support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following example:


class Z {
    private getZ1() {}
    private static getZ2() {}
    
    private int z3
    private static int z4
    
    private Closure z5 = {}
    private static Closure z6 = {}
    
    private enum Z7 { A }
    private static enum Z8 { A }
    
    private class Z9 {}
    private static class Z10 {}
}

There should be no proposals and everything should be underlined in the following examples:


Z z = new Z()

z.getZ1()
Z.getZ2()

z.z3
Z.z4

z.z5()
Z.z6()

Z.Z7.A
Z.Z8.A

new Z.Z9()
new Z.Z10()

Currently it appears as though content assist will propose the private memebers and the editor will infer / resolve them as well. This should not be the case.



 Comments   
Comment by Bob Tiernay [ 29/Jan/12 ]

This issue only applies to when outside the enclosing class.

Comment by Andrew Eisenberg [ 29/Jan/12 ]

This is not a bug. In groovy, you are allowed to access private members from other classes. The editor shows that as allowable.

I could imagine a feature where (optionally) the editor warns you when you do this, but that is quite a different issue than you are describing.

Comment by Bob Tiernay [ 29/Jan/12 ]

Wow, didn't even know this was the case. Sorry for the issue.

Comment by Bob Tiernay [ 30/Jan/12 ]

Well, it looks as though this is really a bug in groovy:

http://jira.codehaus.org/browse/GROOVY-1591
http://jira.codehaus.org/browse/GROOVY-1063
http://jira.codehaus.org/browse/GROOVY-1875

that is slated for correction in 2.0:

http://jira.codehaus.org/browse/GROOVY-3010

Perhaps this issue should be reopened and deferred until then?

Another option that would be valuable to the user is a global preference that allows the user to prevent such proposals and inferencing in preparation for this breaking change in the 2.0 MOP.

Thoughts?

Comment by Andrew Eisenberg [ 30/Jan/12 ]

I guess this needs to be re-opened with a target of Groovy-Eclipse 2.7 (or whatever will come after 2.6 and will have Groovy 2.0 in it).

Comment by Andrew Eisenberg [ 21/Feb/12 ]

Resolving this issue again. I chatted with Jochen about this and nothing will be changed in this area until Groovy 3.0 at the earliest.





[GRECLIPSE-1357] Add "Assign statement to new local variable" (CTRL+2L) quick fix Created: 29/Jan/12  Updated: 24/Apr/12  Resolved: 24/Apr/12

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Stephanie Van Dyk
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File org.codehaus.groovy.eclipse.ui.patch     Text File org.codehaus.groovy.eclipse.ui.patch    
Number of attachments : 2

 Description   

This is a very commonly used quick fix in the Java editor. It allows you to do the following:

new Object()//CTRL + 2L

to produce:

Object object = new Object()


 Comments   
Comment by Stephanie Van Dyk [ 09/Mar/12 ]

I've started working on this.

Comment by Andrew Eisenberg [ 09/Mar/12 ]

Have a look at org.eclipse.jdt.core.NamingConventions.suggestVariableNames(int, int, String, IJavaProject, int, String[], boolean).

Not all of the fields will be relevant, and as we mentioned, there is no need to infer the type of the variable.

One thing that we didn't mention is that it is not a good idea to propose any names that are already in scope. However, as a first pass at this, let's not worry about it.

Lastly, we need to figure out how to hook this into the existing keybindings, but first get the basic working and then we will work on keybindings.

Comment by Bob Tiernay [ 10/Mar/12 ]

Something I just thought about was multiple assignment. Not sure if this is easy to support or should be supported, but it is something to think about.

For example:

[1,2]//CTRL + 2L

by way of the refactoring could produce:

def (x, y) = [1,2]

Similarly:

List f() {
  [1, 2]
}
...
f()//CTRL + 2L

by way of the refactoring could produce:

List f() {
  [1, 2]
}
...
def (x, y) = f()
Comment by Bob Tiernay [ 10/Mar/12 ]

Also, should the refactoring ask the user if the local variable should be typed? Or should it always use the inferred type?

Comment by Stephanie Van Dyk [ 10/Apr/12 ]

Here's the quick assist. A few points:

This assist is not intelligent about lists - it just assigns one name to the list and selects this new name so the user can change it if desired. If this is a highly desired feature, perhaps this choice can be re-evaluated.

This fix makes a reasonable guess of a name based on the statement.

Additionally, this assist is not available for statements that are return statements - either explicitly or implicitly.

In terms of the key-binding, I sunk a few hours into it but I had no luck with it. Since the end of term is approaching, I wanted to share what I have.

Finally, this fix is dependent on a helper function contained in the patch attached to GRE1346.

Stephanie

Comment by Andrew Eisenberg [ 12/Apr/12 ]

I finally got a chance to look at your patch (apologies, still on vacation, so I must do it during nap time). This looks quite good, but there are some comments:

  1. The test suite looks good and it passes for me.
  2. The class comments on the AssignStatementToNewLocalProposal and AssignStatementToNewLocalRefactoring have not been updated.
  3. For list and map literals, I'd rather see the name of the extracted variable be list and map respectively. Currently, it is temp.
  4. The missing functionality is fine, but you should raise new issues for the following:
    1. The key-binding issue
    2. Lack of extraction at return statements
    3. Type inferencing of the extracted variable type
    4. Linked editing mode for the extracted variable name and its type (see the same quick assist in Java).
Comment by Andrew Eisenberg [ 13/Apr/12 ]

I am committing our current patch. So, can you make sure that any changes you make are based on top of head?

Comment by Stephanie Van Dyk [ 15/Apr/12 ]

Thanks, Andrew!

Here's another patch. It addresses the following issues:

  • comments in AssignStatementToNewLocalProposal and AssignStatementToNewLocalRefactoring are fixed
  • guessed names for lists and maps are more intelligent (list and map, as requested)

About the return statement thing: doing so changes the meaning of the code in a fairly insidious way - because of Groovy's implicit return statement, a method will suddenly return void that perhaps had a more meaningful return value. Are we sure this is something we want to do? The Java version ignores return statements. I could go either way on this.

As for type-inferencing, linked editing mode and the key-binding, I will address those shortly. Seperate issues for each?

Thanks,
Stephanie

Comment by Andrew Eisenberg [ 24/Apr/12 ]

Resolving this issue. The final patch looks good.

Please remember to raise the issues for the uncompleted work.





[GRECLIPSE-1356] Content assist property proposal missing due to field Created: 29/Jan/12  Updated: 21/Feb/12  Resolved: 21/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following script:

class P {
    private int value = 1
    int getValue() { return value}
}

P p = new P()
p.value

p.value resolves to private int value and not to the int getValue() method. It therefore shows as a field and not as a property.

This is also true with the class is defined this way:

class P {
    private int value = 1
}

P p = new P()
p.value

When the class is defined in the following way, the property appears as a proposal:

class P {
    int getValue() { return 1}
}

P p = new P()
p.value

Also it seems incorrect to propose private fields (or any private member type for that matter)



 Comments   
Comment by Andrew Eisenberg [ 21/Feb/12 ]

Resolving this as won't fix since as described in GRECLIPSE-1358, private members are accessible outside their scope.

I think the only real problem here is that sometimes proposals show the wrong accessibility when there is a field and a property defined with the same name.

At this point, I won't do anything about this. If you think there is something more fundamentally the problem, then feel free to comment and I'll take another look.





[GRECLIPSE-1355] Formatter splitting single list element into multiple lines Created: 27/Jan/12  Updated: 02/Oct/12  Resolved: 29/Sep/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Minor
Reporter: Peter Larson Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.8.1


Issue Links:
Duplicate
is duplicated by GRECLIPSE-1488 When a List initializer has more than... Resolved
Number of attachments : 0

 Description   

Related to: GRECLIPSE-827

Groovy formatter is splitting list with a single (long) element onto multiple lines. I would think that (although the element contained is large) there isn't much benefit to trying to split this when it only results in new lines with only [ or ]

grails.plugins.springsecurity.interceptUrlMap = [
			        '/js/**': ['IS_AUTHENTICATED_ANONYMOUSLY'],
				'/css/**': ['IS_AUTHENTICATED_ANONYMOUSLY'],

becomes

                                '/js/**': [
					'IS_AUTHENTICATED_ANONYMOUSLY'
				],
				'/css/**': [
					'IS_AUTHENTICATED_ANONYMOUSLY'
				],


 Comments   
Comment by Marc Paquette [ 28/Sep/12 ]

Reading GRECLIPSE-827, I see there is a criteria for the "long-ness" of a list : frankly, I expected the code formating setting for "maximum line width" in the "Line Wrapping" section to be the one having the last word on this.

Either that or it should have a separate setting user-modifiable controlling that limit.

It is terribly annoying to have a list being broken up in lines when it is not expected. For example, if you are designing a DSL where tabular data is natural, you will probably end up having somewhat long lists that you will want aligned accross lines; actual behavior breaks this big time.

Comment by Andrew Eisenberg [ 28/Sep/12 ]

I will be adding a new user controlled setting called 'Long list length'. This will just be a way to expose the constant that was used internally to determine how/when to wrap lists. The default is what it has been before, 30. And you can bump that up (or down) if you like.

Would this be sufficient for you?

Comment by Andrew Eisenberg [ 28/Sep/12 ]

I am committing a fix that will go into the next snapshot build that adds this new Long list length setting to the Preferences -> Groovy -> Formatter page. Please try this out and get back to me if this works for you or if there's something different you'd like to see.

Comment by Marc Paquette [ 02/Oct/12 ]

Thanks Andrew, looks very good to me.

As the actual value of the limit goes, I'm not sure I understand fully how to interpret "30" versus "200". It is not the column number (I would guess) but with 30, my list was re-formated while with the upper-limit, 200, it was left alone (as wanted).

So my list was considered as having more than 30 "things" but I can't count anything other that characters that goes over this; at the same time, if these are chars, each line has more than 200 characters but they are not re-formatted !

Comment by Andrew Eisenberg [ 02/Oct/12 ]

The value is the number of characters inside of the [ ] excluding leading/trailing whitespace. I guess that's not entirely clear from the description. I'll can make that more explicit. Thanks for the feedback.





[GRECLIPSE-1352] Cannot complete the install because of a conflicting dependency. Created: 25/Jan/12  Updated: 24/May/12  Resolved: 27/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.5.0Release, 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Paul Jungels Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP3, Rational Application Developer 8.0.4 (Eclipse 3.6.2)


Attachments: JPEG File Groovy-Eclipse Install Details.JPG     JPEG File Groovy-Eclipse Site.JPG    
Issue Links:
Duplicate
is duplicated by GRECLIPSE-1437 Error while building the java-groovy ... Resolved
Number of attachments : 2

 Description   

When I attempt to install the 2.5.0 Groovy-Eclipse plug-in on RAD 8.0.4, I get the following message:

Cannot complete the install because of a conflicting dependency.
Software being installed: Groovy-Eclipse Feature 2.5.0.xx-20110511-1600-e36-RELEASE (org.codehaus.groovy.eclipse.feature.feature.group 2.5.0.xx-20110511-1600-e36-RELEASE)
Only one of the following can be installed at once:
Java Development Tools Core 3.5.2.20101020-2100-e35-release (org.eclipse.jdt.core 3.5.2.20101020-2100-e35-release)
Java Development Tools Core 3.6.2.xx-20110511-1600-e36-RELEASE (org.eclipse.jdt.core 3.6.2.xx-20110511-1600-e36-RELEASE)
Java Development Tools Core 3.6.4.v_A79_R36x (org.eclipse.jdt.core 3.6.4.v_A79_R36x)
Java Development Tools Core 3.6.2.xx-20111212-0800-e36-RELEASE (org.eclipse.jdt.core 3.6.2.xx-20111212-0800-e36-RELEASE)
Java Development Tools Core 3.7.1.xx-20111212-0900-e37-RELEASE (org.eclipse.jdt.core 3.7.1.xx-20111212-0900-e37-RELEASE)
Cannot satisfy dependency:
From: Groovy-Eclipse Feature 2.5.0.xx-20110511-1600-e36-RELEASE (org.codehaus.groovy.eclipse.feature.feature.group 2.5.0.xx-20110511-1600-e36-RELEASE)
To: org.codehaus.groovy.jdt.patch.feature.group [2.5.0.xx-20110511-1600-e36-RELEASE]
Cannot satisfy dependency:
From: JDT Core patch for Groovy-Eclipse plugin 2.5.0.xx-20110511-1600-e36-RELEASE (org.codehaus.groovy.jdt.patch.feature.group 2.5.0.xx-20110511-1600-e36-RELEASE)
To: org.eclipse.jdt.feature.group [3.6.0,3.7.0)
Cannot satisfy dependency:
From: Data Tools Platform JDT Enablement 1.8.2.v201010181125-2-07w31211518181A (org.eclipse.datatools.enablement.jdt.feature.feature.group 1.8.2.v201010181125-2-07w31211518181A)
To: org.eclipse.jdt.feature.group 3.4.0
Cannot satisfy dependency:
From: Eclipse Java Development Tools 3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F (org.eclipse.jdt.feature.group 3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F)
To: org.eclipse.jdt.ui [3.6.2.r362_v20110203]
Cannot satisfy dependency:
From: Eclipse Plug-in Development Environment 3.6.2.r362_v20110203-7b7mFL2FET3dhHalh1iNZtL (org.eclipse.pde.feature.group 3.6.2.r362_v20110203-7b7mFL2FET3dhHalh1iNZtL)
To: org.eclipse.jdt.feature.group [3.6.0,4.0.0)
Cannot satisfy dependency:
From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.5.0.xx-20110511-1600-e36-RELEASE Eclipse Java Development Tools 3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F (org.eclipse.jdt.feature.group 3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F)
To: org.eclipse.jdt.core [3.6.2.xx-20110511-1600-e36-RELEASE]
Cannot satisfy dependency:
From Patch: org.eclipse.jdt.R362patch.feature.group 1.0.6 Eclipse Java Development Tools 3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F (org.eclipse.jdt.feature.group 3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F)
To: org.eclipse.jdt.core [3.6.4.v_A79_R36x]
Optional dependency

We are using a local repository for the plugin (see screen print). When I try to use the distribution URL (http://dist.springsource.org/release/GRECLIPSE/e3.6/) I get a similar error message.



 Comments   
Comment by Andrew Eisenberg [ 25/Jan/12 ]

This problem has come about because of some oddities about the way RAD is distributing its plugins. We had a long discussion about this on the mailing list a few months ago. There is no clean way around this, although Thomas was able to get this working in the end:

http://groovy-eclipse-plugin.42567.n3.nabble.com/2-6-0-from-10-November-lacking-refactor-td3500416.html

What seemed to work was this:

  1. start with a fresh and slightly older RAD installation (that uses Eclipse 3.6.2 or earlier).
  2. install groovy-eclipse
  3. update RAD

The issue seems to be that RAD includes its own patches to JDT that cause Groovy-Eclipse's patch to be uninstallable. But, if you install Groovy-eclipse first, then you can install RAD's feature patches. These feature patches contain small bug fixes that are unlikely to affect you.

Comment by Paul Jungels [ 27/Jan/12 ]

After rolling back to RAD 8.0.1 I was able install the plugin then re-update RAD (with some fiddling of the vmargs when launching Installation Manager - https://www-304.ibm.com/support/docview.wss?uid=swg21424419).

Comment by Andrew Eisenberg [ 27/Jan/12 ]

Unfortunately, there's not much more that we can do here. It is good that there is a workaround that suffices for you. Please raise a new issue if you have any more problems.





[GRECLIPSE-1351] Add content assist support for static imports Created: 24/Jan/12  Updated: 23/Jul/14  Resolved: 23/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: None
Fix Version/s: 2.9.1.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Vasiliy Kizhaev
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It seems as though content assist is not supported when attempting to import static members.

In the following example:

import static Boolean.F//CTRL + Space

no content proposals are suggested.

This feature is useful when working with DSLs to produce less clutter with added type safety when compared to import static Boolean.*



 Comments   
Comment by Bob Tiernay [ 28/Jul/12 ]

Any chance this is low hanging fruit? This would be a very welcome addition.

Comment by Andrew Eisenberg [ 28/Jul/12 ]

I'll try to get this done for 2.7.1

Comment by Vasiliy Kizhaev [ 21/Jul/14 ]

A PR for the issue was submitted: https://github.com/groovy/groovy-eclipse/pull/69

Comment by Vasiliy Kizhaev [ 23/Jul/14 ]

The PR is merged, closing issue.





[GRECLIPSE-1349] Allow dot (".") to accept a proposal of code assist Created: 22/Jan/12  Updated: 23/Jan/12  Resolved: 22/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider the following Java class:

package test;

public class J
{
	private String myProperty1 = "HELLO1";
	private String myProperty2 = "HELLO2";

	private void myMethod()
	{
		myProp|
	}
}

Go to | and hit ctrl+space: the code assist will propose myProperty1 and myProperty2. Hit the down arrow to select myProperty2 and hit "." (the dot key): the Java editor will complete to "myProperty2.", so that you can then start to type any other String method (like "toUpperCase" for instance...).

Now try the following Groovy class

package test

class G {
	private String myProperty1 = "HELLO1"
	private String myProperty2 = "HELLO2"

	private void myMethod() {
		myProp|
	}
}

Try to do the same as before: unfortunately, the Groovy editor does not recognize "." as a confirmation of the selected proposal, so "myProp." is the result. You must do the following to complete to myProperty2: myProp -> ctrl+space -> enter -> dot -> ...

I use the "dot" to accept the code assist proposals a lot to speed up code typing. Having it in the Groovy editor would be really appreciated.



 Comments   
Comment by Andrew Eisenberg [ 22/Jan/12 ]

Hmmm...not the way that I work, so never noticed this problem. I'm imagining this shouldn't be difficult to fix.

Comment by Andrew Eisenberg [ 22/Jan/12 ]

Looks like we are not properly calling setTriggerCharacters to set the things that trigger content assist to be applied.

The complicating factor is that there should be different triggers depending on the situation. But, getting this working for peroperties would be a good first step.

Comment by Andrew Eisenberg [ 22/Jan/12 ]

Done. In addition to '.' for variables and fields, I followed the same conditions that JDT uses for methods and types. For example, now you can do '(' to add a type or method, etc.

Comment by Mauro Molinari [ 23/Jan/12 ]

Thank you Andrew, very much appreciated!

Comment by Andrew Eisenberg [ 23/Jan/12 ]

Still some failing tests on the build server, so not available yet, but will be later today.





[GRECLIPSE-1347] Argument names missing in method declaration when using code assist to implement missing methods Created: 22/Jan/12  Updated: 06/Aug/12  Resolved: 26/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.1.M1
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Create a Groovy project and write the following interface:

package test;

public interface I
{
	void myMethod(String a, int b);
}

Then create a new Groovy class with the following contents:

package test

class A implements I {
  |	
}

Move the cursor to "|" and hit ctrl+space. Choose to override myMethod method in I. What I see is this:

package test

class A implements I {
	void myMethod(String arg0, int arg1) {
		// TODO Groovy Auto-generated method stub
		// Only partially implemented. Perform organize imports
		// to properly import parameter and return types
	}
}

What I would expect is this:

package test

class A implements I {
	void myMethod(String a, int b) {
		// TODO Groovy Auto-generated method stub
		// Only partially implemented. Perform organize imports
		// to properly import parameter and return types
	}
}


 Comments   
Comment by Andrew Eisenberg [ 26/Jan/12 ]

It looks like if the super type is in the same file, then you do get the argument names, otherwise you get the broken ones.

This may be a good time to try to fix the implementation of the method proposals.

Comment by Andrew Eisenberg [ 26/Jan/12 ]

Wow. Turns out that with a little bit of tweaking, I can use JDT's OverrideMethodCompletionProposal. So, with this implemented, you will have exactly the same functionality in Groovy as you do with Java. However, it does not look like it will be easy to properly handle situations where the super type is parameterized.

Comment by Andrew Eisenberg [ 26/Jan/12 ]

Fixed the problem with generic super types. Also, comments and override annotations will be properly generated.

Comment by Andrew Eisenberg [ 26/Jan/12 ]

Return statements will have a semi-colon (since functionality is borrowed from Java), but I think that is acceptable.

Comment by Andrew Eisenberg [ 26/Jan/12 ]

Committed the fix for this.

Comment by Mauro Molinari [ 27/Jan/12 ]

For me, the presence of the semicolons is absolutely acceptable. Maybe you can tweak it, if you wish, by applying a subsequent "quick fix" invocation to remove unneeded semicolons on the inserted code fragment immediately after?

Comment by Andrew Eisenberg [ 27/Jan/12 ]

Created GRECLSIPE-1353 to discuss ways of making the proposal application more groovy-like. Add more things to fix if you can think of anything.

Comment by Mauro Molinari [ 15/Apr/12 ]

Hi Andrew,
I'm using GRECLIPSE version 2.6.1.xx-20120301-1000-e37-RELEASE and I'm still seeing problems in this scenarios.

The simple test case reported here works, even if there's the following secondary problem: if you put your cursor inside A class body and type my then invoke code assist, the code assist window says:

myMethod(String arg0, int arg1): void - Override method in 'I'

If you accept the proposal, public void myMethod(String a, int b) is correctly inserted, instead of public void myMethod(String arg0, int arg1).

However there's a different scenario in which insertion is also wrong (i.e.: with missing argument names). Try this:

package greclipse1347

class B {
  void test() {
    I myvar = new I(){
      my|
    }
  }
}

Invoke code completion after my and accept the proposal of myMethod (by the way, it wasn't immediately visible to me, maybe I had to save the file for the proposal to show the first time... I don't know exactly). This is what is inserted for me:

void myMethod(String arg0, int arg1) {};

Not only argument names are missing, but there is the semicolon after the closing bracket and the code isn't formatted (i.e.: opening and closing brackets on the same line, no comments about auto generations, etc.).

Another strange thing is that if you place the cursors inside new I()

{ ... }

and you don't use contents assist at "my|" to implement the missing method, but you try to invoke right click -> Source -> Override/implement methods, it seems like it isn't recognized that I am inside the definition of an I instance, since the only methods I can select in the "Override/Implement methods" window are those of java.lang.Object.

Comment by Andrew Eisenberg [ 15/Apr/12 ]

There's a lot that is not fully implemented with regards to inner/anonymous classes. This is not a problem with content assist, but with inner classes. Can you please raise a new bug for this with your comment above and it will specifically target inner/anonymous classes.

Comment by Mauro Molinari [ 16/Apr/12 ]

I opened GRECLIPSE-1426, thank you.
And what about the missing argument names in the code assist window, even in the case of this issue? Should I also open another ticket for that?

Comment by Mauro Molinari [ 06/Aug/12 ]

I opened GRECLIPSE-1473 for the missing argument names in the code assist window.





[GRECLIPSE-1346] Convert Local Variable to Field Created: 21/Jan/12  Updated: 16/May/12  Resolved: 16/May/12

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: New Feature Priority: Major
Reporter: Daniel Phan Assignee: Daniel Phan
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ExtractLocalToFieldRefactoring.patch     Text File local-to-field-2.patch     Text File local-to-field.patch     JPEG File screenshot-1.jpg     File Test.groovy    
Number of attachments : 5

 Description   

We want to add a refactoring that is similar to Eclipse's Convert Local Variable to Field (i.e. promote local variable.)

For example,

class Foo {
  def bar(a, b) {def c = 0}
}

becomes

class Foo {
  def c
  def bar(a, b) {c = 0}
}


 Comments   
Comment by Andrew Eisenberg [ 21/Jan/12 ]

One thing to look at is how reusable the existing convert to field refactoring wizard is. For example, in the screenshot, could we have a section for where to initialize the field? Also, being able to specify an access parameter is nice.

Comment by Daniel Phan [ 10/Feb/12 ]

I've attached what I have so far. It compiles and displays the first page of the wizard, but doesn't actually perform the refactor yet.

Comment by Andrew Eisenberg [ 12/Feb/12 ]

Thanks for the initial patch. This is a good start. I haven't run the code, but I eyeballed it. Two comments so far:

  1. It looks like you copied the messages in check initial/final conditions from Extract constant refactoring. Make sure to update all of the messages to something reasonable for convert local to field.
  2. I do see the copied code from Extract constant. Best thing to do for now is to mark each copied section with a comment. And once the functionality is there we can decide what to do. 3 possibilities really, and it's hard to say what the best option is until we see how much copied code there really is):
    1. Leave as is
    2. Extract copied code to a utility class and convert to static methods
    3. Extract an abstract common super class for Extract constant and convert to field. Put the common code in the super class.

With the copied code, it's best for now to mark the copied segments and change as little as possible inside of them so that when it comes time to refactor, then we will have the easiest time doing it.

Comment by Andrew Eisenberg [ 12/Feb/12 ]

Two more comments:

  1. Do not include the .classpath changes in the path. They should not be committed.
  2. And for the changes to FindSurroundingNode, I need to be very careful with those changes so that they don't break existing code. It looks like your changes to not cause testing failures, but I'll have a deeper look later. Also, keep this in a separate patch for now.
Comment by Daniel Phan [ 09/Mar/12 ]

Here is a file that I've been using for manual testing and debugging that contains some interesting cases (at the bottom).

Comment by Daniel Phan [ 09/Mar/12 ]

Still needs to be done:

  • Test.groovy cases added to test suite
  • Existing tests in suite updated to match correct behaviour
  • Fix all the FIXMEs
Comment by Andrew Eisenberg [ 13/Mar/12 ]

Thanks for the update. This is on the right track. Some comments:

  1. Add some comments to the tricky parts of your code, like in getDeclarationExpression, createFieldText, and any other place that is potentially tricky.
  2. There is no concept of final in Groovy, so you can ignore that part of the refactoring.
  3. getRefactoringDescriptor is not something we are supporting right now, so you don't need to implement the method. This method is supposed to enable scripting your refactoring changes, but it doesn't really work (even in Java), so there's not much point in putting much effort into it.
  4. Rather than use the existing PromoteTempWizard, it would be better to sub-class it and disable functionality that you will not be supporting (eg- final, initialize in field, initialize in constructor, etc). Or if you prefer, you can copy the entire class and place it in the refactoring plugin and then make edits to simplify the wizard. See here for how to copy code: http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+coding+conventions

I have not actually applied the patch or run the tests. Let me know if you think you are ready for me to do that.

Comment by Daniel Phan [ 10/Apr/12 ]

The feature and tests are complete. Please take a look at the attached patch and add your feedback.

Comment by Andrew Eisenberg [ 12/Apr/12 ]

Thanks. This is looking really close. A few small comments:

  1. I am getting 3 test failures. Are they failing for you? It looks like the Local variable is not being properly found and so the extraction cannot occur. If they are passing for you, or you need me to take a deeper look, I can.
    1. testForLoop
    2. testPostfix
    3. testPrefix
  2. You have a bunch of TODO statements in the extract refactoring class. It is fine to leave these sections unimplemented, but there should not be a TODO comment there. If you plan on implementing this functionality later, change the comment to FIXDP (your initials) and include a comment as to what needs to happen. Or if you don't plan on implementing, then the same comment explaining what is left undone, but without the FIXDP is fine. In either case, a link to a relevant jira is good.
  3. After you have done these two things, you should raise a new jira explaining what is left to do (even if you don't think you will get to it or if it is even worth doing ever).
Comment by Andrew Eisenberg [ 12/Apr/12 ]

I dug a little deeper and it looks like the failing tests are due to the problems that you discovered with the FindSurroundingNode class. I made the fixes for that class and reran the tests. They all passed.

I am now writing some more tests for FindSurroundingNode to ensure that the changes don't break anything. I don't think we ever raised a jira for that.

Comment by Andrew Eisenberg [ 13/Apr/12 ]

I fixed the problem with FindSurroundingNode. See GRECLIPSE-1424. All of your tests are passing for me now.

I will commit the current patch and then can you submit a new patch to update the comments? This way your next patch can be significantly smaller.

Comment by Daniel Phan [ 16/May/12 ]

The improvements have been listed in GRECLIPSE-1436.

Comment by Andrew Eisenberg [ 16/May/12 ]

Resolving. Added a link to the bug report in the code.

Comment by Andrew Eisenberg [ 16/May/12 ]

Link to pull request. https://github.com/groovy/groovy-eclipse/pull/1





[GRECLIPSE-1344] ASTNodeFinder does not visit binary expressions Created: 20/Jan/12  Updated: 20/Jan/12  Resolved: 20/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ASTNodeFinder.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

We would like the ASTNodeFinder to return the BinaryExpression in this case when selecting on the '='

foo = 9

But, ASTNodeFinder does not explicitly check BinaryExpressions.



 Comments   
Comment by Daniel Phan [ 20/Jan/12 ]

Here's the fix.

Comment by Andrew Eisenberg [ 20/Jan/12 ]

Thanks. Fix is applied.





[GRECLIPSE-1342] Assign to local variable quick assist Created: 19/Jan/12  Updated: 04/Jul/12  Resolved: 04/Jul/12

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.7.0.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Assign a statement to a local variable. For example:

foo.bar('abc')

becomes:

def blah = foo.bar('abc')

Just like the same quick assist in Java.



 Comments   
Comment by Andrew Eisenberg [ 04/Jul/12 ]

Done.





[GRECLIPSE-1341] OptimizingStatementWriter damages type inferencing for declarations Created: 16/Jan/12  Updated: 18/Jan/12  Resolved: 17/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Inferencing Engine
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In this code, substring is underlined.

class Problem2 {
	String action() { }
	def meth() {
		def x = action()
		x.substring()
	}
}

Digging down into why, it seems that the problem comes from OptimizingStatementWriter. This class sometimes converts DeclarationsExpression}}s to {{BinaryExpression}}s. When this happens, {{x is not inferred to be a String. OptimizingStatementWriter is run during the classgen phase. Why are we running classgen during a reconcile? Would we get around this problem if we stopped doing classgen for reconciles?



 Comments   
Comment by Andy Clement [ 17/Jan/12 ]

enabled SourceUnits to know if it is a reconcile and then use the standard (non optimizing) statement writer.

As discussed, some errors are produced in classgen, we would lose the ability to show those in reconcile if we turned it off.

Comment by Andrew Eisenberg [ 18/Jan/12 ]

Thanks for the quick turnaround. I just committed a regression test on the inferencer for this.





[GRECLIPSE-1339] Exchange left and right operands for infix expression Created: 16/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File swap-operands.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Convert this:

if (x && y) { 
}

to:

if (y && x) { 
}

Should be able to work whenever there is a binary expression is used and for all operators that it makes sense for (eg- ||, &&, ==, +, -, <<...).



 Comments   
Comment by Daniel Phan [ 20/Jan/12 ]

I'm going to start working on this bug. I will assign this bug to myself when I receive permissions.

Comment by Stephanie Van Dyk [ 20/Jan/12 ]

Here's the fix! - Steph and Daniel

Comment by Andrew Eisenberg [ 21/Jan/12 ]

Thanks for the patch. I wasn't able to get to it tonight, but I'll have a look tomorrow.

Comment by Andrew Eisenberg [ 21/Jan/12 ]

Nice work. I committed the patch. I added a few extra test cases just to ensure this works when the expression is at the start of the file.





[GRECLIPSE-1338] Split assignment quick assist Created: 16/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File SliptAss.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

convert this:

def foo = bar

to this:

def foo
foo = bar


 Comments   
Comment by Elvis Martinez [ 21/Jan/12 ]

Here it is!!

Comment by Andrew Eisenberg [ 21/Jan/12 ]

Fix is committed. Great work! Thanks for the patch.





[GRECLIPSE-1337] Split assignment quick assist Created: 16/Jan/12  Updated: 19/Jan/12  Resolved: 19/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

convert this:

def foo = bar

to this:

def foo
foo = bar


 Comments   
Comment by Andrew Eisenberg [ 19/Jan/12 ]

duplicate





[GRECLIPSE-1331] Invalid property proposals in content assist Created: 15/Jan/12  Updated: 23/Jan/12  Resolved: 23/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script:

// (1)
def text = value

public String getValue(String s) { return s }

value appears in content assist at (1) and resolves to getValue. This is incorrect as it is not a property since it takes an argument, even though it begins with get



 Comments   
Comment by Bob Tiernay [ 15/Jan/12 ]

Similar issues with the following:

public void setFoo() {}
public void setBar(int x, int y) {}
public String setBaz() {}
Comment by Bob Tiernay [ 15/Jan/12 ]

A more complete test suite:

println property1
println property2
println property3
println property4
println property5
println property6
println property7
println property8

// Getter with arg
public String getProperty1(param){}

// Getter with void return
public void getProperty2(){}

// Boolean getter with arg
public boolean isProperty3(param){}

// Boolean getter with non-boolean return type
public String isProperty4(){}

// Boolean getter with void return type
public void isProperty5(){}

// Setter without arg
public void setProperty6(){}

// Setter with multiple args
public void setProperty7(param1, param2){}

// Setter with non-void return type
public String setProperty8(param){}

Should also consider static variants

Comment by Andrew Eisenberg [ 23/Jan/12 ]

The code for handling getter and setter conversion is split across several locations. This should be refactored.

Comment by Andrew Eisenberg [ 23/Jan/12 ]

A more complete test would also look at categories. Here is the test case that I am using. Notice that categories doe not accept isser methods (this is just a bug in groovy).

// yes underlines and no content assist
String getProperty1(param){}
void getProperty2(){}
boolean isProperty3(param){}
String isProperty4(){}
void isProperty5(){}
void setProperty6(){}
void setProperty7(param1, param2){}
String setProperty8(param){}

// no underlines and yes content assist
def setProperty1a(param) {}
void setProperty2a(param) {}
def getProperty3a() {}
def isProperty4a() {}

println property1
println property2
println property3
println property4 
println property5
println property6
println property7
println property8



println property1a
println property2a
println property3a
println property4a 

class Cat {
	// yes underlines and no content assist
	static String getPropertyCat1(File self, param){}
	static void getPropertyCat2(File self){}
	static boolean isPropertyCat3(File self, param){}
	static String isPropertyCat4(File self){}
	static void isPropertyCat5(File self){}
	static void setPropertyCat6(File self){}
	static void setPropertyCat7(File self, param1, param2){}
	static String setPropertyCat8(File self, param){}
	static def isPropertyCat9(File self) {}
	def getPropertyCat10(File self) {}
	
	// no underlines and yes content assist
	static def setPropertyCat1a(File self, param) {}
	static void setPropertyCat2a(File self, param) {}
	static def getPropertyCat3a(File self) {}
}
 
use (Cat) {
	println propertyCat1
	println propertyCat2
	println propertyCat3 
	println propertyCat4
	println propertyCat5
	println propertyCat6
	println propertyCat7  
	println propertyCat8
	println propertyCat9
	println propertyCat10
	  
	println propertyCat1a
	println propertyCat2a
	println propertyCat3a
	
}
Comment by Andrew Eisenberg [ 23/Jan/12 ]

With a bit of refactoring and moving things around, inferencing is behaving much better. I added a regression test (the file from above). I haven't added any content assist tests yet, but I will.

Now, all the accessor infrastructure is factored out into a single class, and there are fewer places where things can go wrong.





[GRECLIPSE-1330] Allow "Open Declaration" / CTRL+ Click / F3 on GString expressions without braces Created: 15/Jan/12  Updated: 22/Feb/12  Resolved: 22/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Search
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following script, the variable i cannot be navigated to by "Open Declaration":

def i = 1
def s = "$i"

However, it works as expected with the following:

def i = 1
def s = "${i}"


 Comments   
Comment by Andrew Eisenberg [ 22/Jan/12 ]

I just tried this. I am bumping this down to minor since looks like this only happens for variables that are 1 char long. If I rename the variable to ii, then things work as expected.

I'll see if there is an easy fix anyway.

Comment by Andrew Eisenberg [ 22/Jan/12 ]

Actually, for mark occurrences, there was a bit more of an issue since the editor was considering the '$' to be part of the variable name, which was messing things up and I fixed this as well.

Fixed with regression tests.

Comment by Bob Tiernay [ 23/Jan/12 ]

Although F3 and "Open Declaration" seem to work, CTRL + Clicking does not.

Comment by Bob Tiernay [ 24/Jan/12 ]

Reopening to see if this is still an issue.

Comment by Andrew Eisenberg [ 21/Feb/12 ]

Not able to reproduce with the example given. Please provide a failing test, and I'll look into this again.

Comment by Bob Tiernay [ 21/Feb/12 ]

I just verified that this still does not work for me on 2.6.1.xx-20120213-1100-e37

def variable = 1
def text = "$variable" // Cannot navigate to def variable by CTRL + Clicking on "$variable"
Comment by Andrew Eisenberg [ 21/Feb/12 ]

OK...now you got it.

Looks like the problem is that when there are no curlies, navigation doesn't work, but it does when the curlies exist.

Comment by Andrew Eisenberg [ 22/Feb/12 ]

More specifically, the problem is that the selection is calculated differently based on whether CTRL+Click is used vs F3. For F3, the caret location is used as the selection to analyze, but CTRL+Click takes the character under the mouse pointer and expands that to be the entire word. In this case, the word includes the trailing $, since that is a valid identifier part.

Either, I need to change the selection before analyzing it, or I need to ensure that the code selection visitor can handle trailing $ inside of GStrings.

Comment by Andrew Eisenberg [ 22/Feb/12 ]

Fixed for real this time. Available in next snapshot build.





[GRECLIPSE-1327] Closure defined and invoked inside static method is underlined Created: 12/Jan/12  Updated: 21/Feb/12  Resolved: 21/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Inferencing Engine
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following code:

static staticMethod() {
    def closure = { -> }
    closure()
}

closure() appears underlined. However, it does not in the following:

def staticMethod() {
    def closure = { -> }
    closure()
}


 Comments   
Comment by Bob Tiernay [ 12/Jan/12 ]

Sorry, the second listing should be:

def instanceMethod() {
    def closure = { -> }
    closure()
}
Comment by Andrew Eisenberg [ 12/Jan/12 ]

Fixed the typo in your listing.

Comment by Andrew Eisenberg [ 21/Feb/12 ]

Fixed. When invoking a closure, the Groovy AST is manipulated so that there is a call AST Node added. This AST node has the same source location as the reference to the closure itself. The semantic highlighter was getting tripped up over this synthetic AST node.

Now, before adding an AST node to the list of unknown references, we first check to see if the text of the AST node matches the text in the file.





[GRECLIPSE-1325] Installing stable and snapshot release of Groovy causes bundles.info to have duplicate versions of JARs and Eclipse bug 365722 Created: 10/Jan/12  Updated: 30/Jan/12  Resolved: 30/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.6.1.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I have an Eclipse installation where I installed version 2.5.2 of the Groovy Eclipse plugin. I then upgraded to 2.6.0 and now I'm running a snapshot of version 2.6.1 (in order to test the fix for GRECLIPSE-1284).

I'm now experiencing Eclipse bug at:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=368184
which is a duplicate of:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=365722

After investigation it seems like that bug manifests itself because of the presence of two different versions of bundle org.codehaus.groovy.frameworkadapter in my <eclipse dir>/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info:

bundles.info
org.codehaus.groovy.frameworkadapter,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.frameworkadapter_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.frameworkadapter,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.frameworkadapter_2.6.1.xx-20120107-0800-e37.jar,4,false

This is not the only bundle for which I have two versions listed in my bundles.info. Here are other ones:

bundles.info
org.codehaus.groovy.eclipse.ant,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.ant_2.5.2.xx-20110921-1600-e37/,4,false
org.codehaus.groovy.eclipse.ant,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.ant_2.6.1.xx-20120107-0800-e37/,4,false
org.codehaus.groovy.eclipse.astviews,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.astviews_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.astviews,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.astviews_2.6.1.xx-20120107-0800-e37.jar,4,false
org.codehaus.groovy.eclipse.codeassist.completion,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.codeassist.completion_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.codeassist.completion,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.codeassist.completion_2.6.1.xx-20120107-0800-e37.jar,4,false
org.codehaus.groovy.eclipse.codebrowsing,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.codebrowsing_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.codebrowsing,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.codebrowsing_2.6.1.xx-20120107-0800-e37.jar,4,false
org.codehaus.groovy.eclipse.core,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.core_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.core,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.core_2.6.1.xx-20120107-0800-e37.jar,4,false
org.codehaus.groovy.eclipse.dsl,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.dsl_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.dsl,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.dsl_2.6.1.xx-20120107-0800-e37.jar,4,false
org.codehaus.groovy.eclipse.quickfix,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.quickfix_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.quickfix,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.quickfix_2.6.1.xx-20120107-0800-e37.jar,4,false
org.codehaus.groovy.eclipse.refactoring,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.refactoring_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.refactoring,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.refactoring_2.6.1.xx-20120107-0800-e37.jar,4,false
org.codehaus.groovy.eclipse.ui,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.ui_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.ui,2.6.1.xx-20120107-0800-e37,plugins/org.codehaus.groovy.eclipse.ui_2.6.1.xx-20120107-0800-e37.jar,4,false

The stable releases of Groovy (2.5.2 and 2.6.0) were installed from:
http://dist.springsource.org/release/GRECLIPSE/e3.7/
The snapshot release (2.6.1) was installed from:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

Is it normal that two versions of those plugins are listed there?



 Comments   
Comment by Andrew Eisenberg [ 10/Jan/12 ]

No. This should not be. I am marking the fragment as a singleton. Hopefully, that should fix the problem with groovy-eclipse.

Comment by Andrew Eisenberg [ 10/Jan/12 ]

Change is committed. Will be available in next snapshot build in about an hour.

Comment by Mauro Molinari [ 11/Jan/12 ]

Hi Andrew, I just updated to GRECLIPSE 2.6.1.xx-20120110-1100-e37, however I still see the following in my bundles.info:

bundles.info
org.codehaus.groovy,1.7.10.xx-20110921-1600-e37,plugins/org.codehaus.groovy_1.7.10.xx-20110921-1600-e37/,4,false
org.codehaus.groovy,1.7.10.xx-20120110-1100-e37,plugins/org.codehaus.groovy_1.7.10.xx-20120110-1100-e37/,4,false
org.codehaus.groovy,1.8.4.xx-20120110-1100-e37,plugins/org.codehaus.groovy_1.8.4.xx-20120110-1100-e37/,4,false
org.codehaus.groovy.eclipse,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse_2.6.1.xx-20120110-1100-e37/,4,false
org.codehaus.groovy.eclipse.ant,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.ant_2.5.2.xx-20110921-1600-e37/,4,false
org.codehaus.groovy.eclipse.ant,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.ant_2.6.1.xx-20120110-1100-e37/,4,false
org.codehaus.groovy.eclipse.astviews,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.astviews_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.astviews,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.astviews_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.groovy.eclipse.codeassist.completion,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.codeassist.completion_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.codeassist.completion,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.codeassist.completion_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.groovy.eclipse.codebrowsing,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.codebrowsing_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.codebrowsing,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.codebrowsing_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.groovy.eclipse.core,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.core_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.core,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.core_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.groovy.eclipse.dsl,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.dsl_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.dsl,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.dsl_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.groovy.eclipse.quickfix,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.quickfix_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.quickfix,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.quickfix_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.groovy.eclipse.refactoring,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.refactoring_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.refactoring,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.refactoring_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.groovy.eclipse.ui,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.eclipse.ui_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.eclipse.ui,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.eclipse.ui_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.groovy.frameworkadapter,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.frameworkadapter_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.frameworkadapter,2.6.1.xx-20120110-1100-e37,plugins/org.codehaus.groovy.frameworkadapter_2.6.1.xx-20120110-1100-e37.jar,4,false
org.codehaus.jackson.core,1.6.0.v20101005-0925,plugins/org.codehaus.jackson.core_1.6.0.v20101005-0925.jar,4,false
org.codehaus.jackson.mapper,1.6.0.v20101005-0925,plugins/org.codehaus.jackson.mapper_1.6.0.v20101005-0925.jar,4,false

As a confirmation, if I try "eclipse -clean" I still suffer from Eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=365722

Comment by Andrew Eisenberg [ 11/Jan/12 ]

Im going to try to reproduce this myself.

Comment by Andrew Eisenberg [ 11/Jan/12 ]

Here's what I tried:

  • Start with fresh Eclipse 3.7.0 SDK
  • Install Groovy-Eclipse 2.6.0 release
  • Upgrade to latest nightly 2.6.1 snapshot

No problems and no duplicate entries in my bundles.info.

What else do you have installed in your Eclipse? Do you have anything that depends on groovy-eclipse?

I can think of a workaround, but this will not fix the underlying problem. You can try this:

  1. Uninstall groovy-eclipse
  2. Shut down eclipse
  3. Make a backup of your bundles.info (just in case something goes wrong)
  4. Remove all org.codehaus.groovy* entries
  5. remove org.eclipse.jdt.groovy.core entries
  6. Restart
  7. Reinstall latest snapshot of Groovy-eclipse

This will likely get you out of the state that you are in. Alternatively, you can start with a fresh Eclipse and re-install everything from scratch.

I am not exactly sure why the extra bundles are staying around. It could be that you have multiple workspaces pointing to the same eclipse installation. The different workspaces may use a different sub-set of the available bundles.

Comment by Mauro Molinari [ 11/Jan/12 ]

I have a lot of installed plugins. I don't know which of them may depend on Groovy, maybe SpringSource Tool Suite-Gradle Integration or some other STS plugin. Could one of them explicitely require the old version, so that it is kept installed (and loaded?) together with the new one?

I'll try your suggestions about uninstalling and re-installing GRECLIPSE...

Regarding the cause of the current situation, maybe the p2 team may shed some light at https://bugs.eclipse.org/bugs/show_bug.cgi?id=368251.

And yes, I'm using the same Eclipse installation on multiple workspaces. But how the workspace may drive the content of the Eclipse installation? Shouldn't be just the opposite?

Comment by Andrew Eisenberg [ 11/Jan/12 ]

I am not a p2 expert, but I believe that each workspace will have its own p2 profile and the profile specifies which sub-set of plugins are active in a given workspace. I don't want to say this too strongly (notice the use of the words could and may in my previous comment) since my understanding of p2 is incomplete.

Comment by Andrew Eisenberg [ 26/Jan/12 ]

Any progress on this bug?

Comment by Mauro Molinari [ 27/Jan/12 ]

Hi Andrew,
I just tried your suggested workaround: uninstall GRECLIPSE, clean bundles.info manually, reinstall, except for the fact that I now installed the 2.6.1.M1 release instead of the latest snapshot (by the way, the update site http://dist.springsource.org/milestone/GRECLIPSE/e3.7 for Eclipse 3.7 is not listed at http://groovy.codehaus.org/Eclipse+Plugin).

It helped to clean the bundles.info a bit, but didnt solve the problem, because there's a funny behaviour. In short, this is the contents of my bundles.info now:

bundles.info
org.codehaus.groovy,1.7.10.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy_1.7.10.xx-20120118-1100-e37-M1/,4,false
org.codehaus.groovy,1.8.4.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy_1.8.4.xx-20120118-1100-e37-M1/,4,false
org.codehaus.groovy.eclipse,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse_2.6.1.xx-20120118-1100-e37-M1/,4,false
org.codehaus.groovy.eclipse.ant,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.ant_2.6.1.xx-20120118-1100-e37-M1/,4,false
org.codehaus.groovy.eclipse.astviews,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.astviews_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
org.codehaus.groovy.eclipse.codeassist.completion,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.codeassist.completion_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
org.codehaus.groovy.eclipse.codebrowsing,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.codebrowsing_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
org.codehaus.groovy.eclipse.core,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.core_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
org.codehaus.groovy.eclipse.dsl,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.dsl_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
org.codehaus.groovy.eclipse.quickfix,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.quickfix_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
org.codehaus.groovy.eclipse.refactoring,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.refactoring_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
org.codehaus.groovy.eclipse.ui,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.eclipse.ui_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
org.codehaus.groovy.frameworkadapter,2.5.2.xx-20110921-1600-e37,plugins/org.codehaus.groovy.frameworkadapter_2.5.2.xx-20110921-1600-e37.jar,4,false
org.codehaus.groovy.frameworkadapter,2.6.1.xx-20120118-1100-e37-M1,plugins/org.codehaus.groovy.frameworkadapter_2.6.1.xx-20120118-1100-e37-M1.jar,4,false
[...]
org.eclipse.jdt.groovy.core,2.6.1.xx-20120118-1100-e37-M1,plugins/org.eclipse.jdt.groovy.core_2.6.1.xx-20120118-1100-e37-M1.jar,4,false

As you can see, all the Groovy bundles are now listed just once... EXCEPT for the org.codehaus.groovy.frameworkadapter bundle, which is the one that is causing this issue.
In fact, if I try "eclipse -clean", I still see the endless loop behaviour.

Any idea on why the 2.5.2 version of that bundle was resurrected and is still kept there?

Comment by Andrew Eisenberg [ 27/Jan/12 ]

I tried to reproduce this again. I started with 2.6.0 RELEASE (the framework adapter is not a singleton here). Then I upgraded to the latest snapshot, where the framework adapter is a singleton.

After that I see:

  1. Two framework adapter jars are in the plugins directory, but
  2. Only one framework adapter entry in bundles.info
  3. restarting with eclipse -clean is not a problem.

Have you tried simply deleting the 2.5.2 framework adapter jar from the plugins directory as well as removing the entry from bundles.info?

If this workaround is ok for you, I will resolve this bug. Based on my own testing, I am fairly certain that we have fixed this problem going forward.

Comment by Mauro Molinari [ 30/Jan/12 ]

Removing the framework adapter JAR in the plugins directory and cleaning the bundles.info again did work. Now eclipse -clean works and the JAR is not "resurrected" in the bundles.info file any more.

Maybe things went in the following way:

  • upgrading from 2.5.2 to 2.6.0 lead to the duplicate entries because the framework adapter was not a singleton
  • upgrading from 2.6.0 to 2.6.1 removed the 2.6.0 entries because the framework adapter became a singleton, however this did not remove the old obsolete 2.5.2 version
    The strange thing is that, framework adapter apart, I also had version 2.5.2 of all the other JARs of GRECLIPSE. I now removed them manually, however there must have been some p2 problem here. Let's see if the p2 devs tell us something.

The issue here can be closed for me, thank you Andrew!

Comment by Andrew Eisenberg [ 30/Jan/12 ]

Thanks for the detailed explanation of what happened in your situation. Now that the framework adapter is a singleton, I don't think others will have the same problem in the future.





[GRECLIPSE-1324] Strange code complete behavior with nested 'setDelegateType' Created: 09/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Sample DSLD descriptor code:

package dsld;

def buildScript = fileExtension("gradle") & ~fileName("settings.gradle")
def settingsScript = fileName("settings.gradle")
def project = buildScript & currentType('org.gradle.api.Project')

(buildScript & isThisType()).accept { 
	setDelegateType('org.gradle.api.Project')
	//delegatesTo type: 'org.gradle.api.Project'
}

(project & enclosingCallName('repositories')).accept {
	setDelegateType('org.gradle.api.artifacts.dsl.RepositoryHandler')
	//delegatesTo type: 'org.gradle.api.artifacts.dsl.RepositoryHandler'
} 

(project & enclosingCallName('dependencies')).accept {
	setDelegateType('org.gradle.api.artifacts.dsl.DependencyHandler')
}

The Project type has an 'allprojects' method which is declared as follows:

    /**
     * <p>Configures this project and each of its sub-projects.</p>
     *
     * <p>This method executes the given {@link Action} against this project and each of its sub-projects.</p>
     *
     * @param action The action to execute.
     */
    void allprojects(Action<? super Project> action);

    /**
     * <p>Configures this project and each of its sub-projects.</p>
     *
     * <p>This method executes the given closure against this project and its sub-projects. The target {@link Project}
     * is passed to the closure as the closure's delegate.</p>
     *
     * @param configureClosure The closure to execute.
     */
    void allprojects(Closure configureClosure);

Sample build script

apply plugin: 'base'

description = 'Spring Security'

allprojects { 
	println "starting allproject block on ${delegate}"
    version = '3.1.1.CI-SNAPSHOT'
    releaseBuild = version.endsWith('RELEASE')
    snapshotBuild = version.endsWith('SNAPSHOT')
	bogus = version.endsWith(description)
	
    group = 'org.springframework.security'
	
    repositories {
        mavenLocal()
        mavenCentral()
    }
	
    dependencies {
       <***>		
    }

}

Delete <***> and place cursor at where it used to be.
Press CTRL-SPACE

Note that the 'allprojects' method is being suggested.

Type 'all'

The content assist list filters down to 'allprojects'.

Press control-SPACE again.
=> the content assist list becomes empty!

Similarly if do not type CTRL-SPACE initially and immediately type 'all' and then press CTRL-SPACE, then the allprojects method is not suggested.

I still have to think about this to decide whether suggesting or not suggesting 'allprojects' is correct... but in any case the suggestions between the first and second press of CTRL-SPACE should allways be consistent.



 Comments   
Comment by Andrew Eisenberg [ 09/Jan/12 ]

Thanks for the good test case. This problem is happening because the scope that we are using to do content assist when the closure block is empty is not the same as it is when there are characters in it. With the empty closure, we are erroneously using the outer scope for content assist.

Comment by Andrew Eisenberg [ 09/Jan/12 ]

The same behavior can be reproduced using the same DSLD and supporting classes, but having this smaller script:

dependencies {  
	
	allprojects
}
Comment by Andrew Eisenberg [ 09/Jan/12 ]

Ah...ok.

When doing inferencing inside of an empty closure, the ITypeLookups are not invoked since they are typically only invoked for identifiers. Normally, this is OK since there really isn't anything to infer about an empty code block.

However, when setDelegateType is being used in a block, the ITypeLookup}}s (secifically, the {{DSLDTypeLookup) must be invoked in order for the delegate to actually be set. However, in an empty block the {{ITypeLookup}}s are not invoked and so the delegate is never set.

For content assist purposes, the DSLDTypeLookup must be invoked for empty blocks.

Comment by Andrew Eisenberg [ 09/Jan/12 ]

OK. I have a solution. This solution ensures that allprojects will not be included in content assist.

Just need to write a few test cases before committing.

Comment by Andrew Eisenberg [ 09/Jan/12 ]

Here is a distilled test case:

DSLD:

contribute(currentType(Integer) & enclosingCallName("foo")) {
	setDelegateType(String)
}

script:

1.foo {
	// here
}

Should have proposals for String, not integer.

Comment by Andrew Eisenberg [ 09/Jan/12 ]

Fixed with regression tests.





[GRECLIPSE-1321] delegatesTo directive in DSLDs selects incorrect method declaration when there is a method and a getter variant of the method Created: 09/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Consider this interface:

public interface Obj {
   String getFoo();
   void foo(arg);
}

and this DSLD:

contribute(currentType(String)) {
  delegatesTo 'Obj'
}

In this script, hovering will show the Obj.foo method, but with a String return type:

"".foo()


 Comments   
Comment by Andrew Eisenberg [ 09/Jan/12 ]

Fix is committed with regression tests. The problem was that the ordering of contributions was not correct. The getFoo contribution was adding the derivative foo property contribution before the foo contribution was adding itself. This means that the foo property was found first.

Changed that and now the delegating methods are added first, and then synthetic properties.





[GRECLIPSE-1320] Remove duplicate content assist proposals in closures Created: 07/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

With the work done in GRECLIPSE-1318, there are now some duplicate content assist proposals being added when inside closures and the delegate and this types are different.

This needs to be fixed.



 Comments   
Comment by Andrew Eisenberg [ 09/Jan/12 ]

Committed fix for this along with regression tests. Here are the major changes:

  1. Now content assist for categories will only try to create proposals based on the delegate type
  2. Content assist for fields and methods will be executed twice if in closure and delegate type != this type and at primary node. After the first time executed, we remember which types we looked at to generate proposals from. So, on the second iteration, these types are not looked at again. For example, this ensures that Object is only looked at once.




[GRECLIPSE-1318] More precise inferencing inside of closures Created: 06/Jan/12  Updated: 06/Jan/12  Resolved: 06/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, the way that we perform inferencing inside of closures is incorrect. We set the this variable to be the type that seems like an appropriate value for delegate. This means that we loose super-type information (see GRECLIPSE-1317). It also means that we can't easily solve GRECLIPSE-1298. And a variant of GRECLIPSE-1297 becomes possible.



 Comments   
Comment by Andrew Eisenberg [ 06/Jan/12 ]

Committed the fix.

Now, the inferencing engine behaves more closely to the way that groovy actually works.

When entering a closure, this is unchanged. delegate is set to the declaring type of the enclosing method call, or this if there is none. owner is set to this if there is no nested closure or groovy.lang.Closure if there is.

And when searching for the declaration of an identifier, first we look at the declarations on delegate and its hierarchy, if it exists, and then we move to this and its hierarchy.





Incorrectly underlined call to valid method declared in super-type, from closure or inner-class (GRECLIPSE-1265)

[GRECLIPSE-1317] Inferencing of methods defined in super class inside of closure. Created: 06/Jan/12  Updated: 06/Jan/12  Resolved: 06/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following code, insuper is underlined in the clsoure.

class MySuper {
	public void insuper(String msg) { println msg }
}

class MySub extends MySuper {
	public void foo() {
		[1].each {
			// same here: line below is underlined; expected it not to be
			insuper("3")
		}
	}


 Comments   
Comment by Andrew Eisenberg [ 06/Jan/12 ]

Fixed. Did a large refactoring of how closures are inferred.





[GRECLIPSE-1315] upgrade to groovy 1.8.5 Created: 05/Jan/12  Updated: 21/Feb/12  Resolved: 21/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 21/Feb/12 ]

Done. Actually, now we are at 1.8.6.





[GRECLIPSE-1314] Early access for Groovy 2.0 complier feature Created: 03/Jan/12  Updated: 05/Mar/12  Resolved: 05/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.7.0.Release

Type: New Feature Priority: Major
Reporter: Renato Garcia Assignee: Unassigned
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Provide early access to Groovy 2.0 snapshot compiler features. This would allow us to test and provide feedback on some of the new features of Groovy 2.0, such as Invoke Dynamic, Static Compilation and Static Type Checking by providing integration with the latest snapshot/Git versions of Groovy 2.0 as they become available for testing/preview.



 Comments   
Comment by Andy Clement [ 05/Mar/12 ]

Think we are going to do this work under the umbrella issue http://jira.codehaus.org/browse/GRECLIPSE-1378





[GRECLIPSE-1313] Add Eclipse-BuddyPolicy:registered to org.codehaus.groovy bundles Created: 03/Jan/12  Updated: 04/Jan/12  Resolved: 04/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In order to augment the classpath of org.codehaus.groovy, it is necessary to add Eclipse-BuddyPolicy:registered to its manifest. The downside of this is that it opens up the bundle to have circular dependencies if used incorrectly. However, this risk is generally low and only applicable for users who actively augment the build path.

The request to use this functionality is here: http://markmail.org/search/?q=eclipse-plugin-user#query:eclipse-plugin-user%20order%3Adate-backward+page:1+mid:xbzl2lxyoyeitven+state:results



 Comments   
Comment by Andrew Eisenberg [ 04/Jan/12 ]

Change is committed. Will be available in next snapshot build.





[GRECLIPSE-1312] Pasting multi-line comments removes leading whitespace Created: 02/Jan/12  Updated: 09/Aug/12  Resolved: 09/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Formatting
Affects Version/s: None
Fix Version/s: 2.7.1.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GRECLIPSE-842 [formatter] Wrong identation on movin... Resolved
Related
is related to GRECLIPSE-773 [formatter] smart paste text containi... Resolved
Number of attachments : 0

 Description   

When pasting the following contents:

/**
 *
 */

The editor will remove the leading whitespace for the second and third lines:

/**
*
*/

This is also true for:

/*
 *
 */

Note, however, this behavior is only observed when there is no text selected prior to the paste operation. If text is selected then the paste procedes as expected.



 Comments   
Comment by Andrew Eisenberg [ 22/Jan/12 ]

See GRECLIPSE-773. The smartPaste method is the likely place to fix this problem.

Comment by Stephanie Van Dyk [ 22/Jan/12 ]

I'm going to look at this.

Comment by Andrew Eisenberg [ 09/Aug/12 ]

Not an issue for me any more, but please comment if you can still reproduce.





[GRECLIPSE-1310] Support for varargs in DSLD scripts Created: 02/Jan/12  Updated: 04/Jan/12  Resolved: 04/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It is possible to specify varargs in DSLD scripts using something like this:

method name:'foo', params:['...values':String]

This is an undocumented feature and we don't know if there are any problems or caveats with it. We need to document this and write tests for it, and make sure there is no odd or unexpected behavior.



 Comments   
Comment by Andrew Eisenberg [ 04/Jan/12 ]

This isn't really varargs. All this is doing is naming the first variable ...values with a type of string. This appears in content assist and hovers, but has no semantic effect. This is fine, but needs to be explained in the documentation. It is no different from doing this:

method name:'foo' params:['a very long param name with special characters !@#$%':String]
Comment by Andrew Eisenberg [ 04/Jan/12 ]

Documentation has been updated. See here:
http://docs.codehaus.org/display/GROOVY/DSL+Descriptors+for+Groovy-Eclipse#DSLDescriptorsforGroovy-Eclipse-ContributionBlocks

I added a test case for parameters with special characters. Not much more to do. Resolving.





[GRECLIPSE-1308] DSLDs should support standard javadoc tags in doc param Created: 31/Dec/11  Updated: 23/Jan/12  Resolved: 23/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It would be very useful if DSLDs supported the standard javadoc feature of tags. See the following for a listing:

http://docs.oracle.com/javase/1.4.2/docs/tooldocs/windows/javadoc.html#javadoctags

This would allow linking between DSLD contributions, linking to classes in the current project, javadoc for params, etc.



 Comments   
Comment by Andrew Eisenberg [ 03/Jan/12 ]

Can you be more specific as to what you want? An example would be good.

Comment by Bob Tiernay [ 03/Jan/12 ]

Sure,

    method name: 'cache', type: 'void', params: [value: boolean], doc: '''\
       Indidates to cache. When {@code value == true} then caching is requested; {@code false} indicates <b>no caching</b>. See {@link java.lang.Boolean#parseBoolean}
     
       @param value - the cache flag
       @return the value supplied
       
       @author btiernay
       @see java.lang.Boolean
       @since 1.2\
    '''
Comment by Andrew Eisenberg [ 03/Jan/12 ]

Ahh...I see. This would be useful to have. In order to get hovers to work properly, I had to do some fairly ugly hacking around JDT UI code. I'll have to see if I can get this working, too.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Not easy. Current implementation is in org.codehaus.groovy.eclipse.editor.GroovyExtraInformationHover. This works fairly crudely by first converting the actual javadoc of the underlying element, and then adding the extra doc on top of that. There is no easy way to alter/augment the actual javadoc of the underlying element before converting it to HTML.

Comment by Andrew Eisenberg [ 06/Jan/12 ]

Actually, found this class org.eclipse.jdt.internal.ui.text.javadoc.JavaDoc2HTMLTextReader. I haven't tried it yet, but it is supposed to convert doc text to html. When I get a chance, I'll try it out.

Comment by Andrew Eisenberg [ 23/Jan/12 ]

The hint in my previous comment seems to be working. I'll commit the fix and close this bug. Will be available in next snapshot build.





[GRECLIPSE-1306] invalid bytecode generated for groovy subclass of parametrized abstract java superclass Created: 28/Dec/11  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Maven integration
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: carlos fernandez Assignee: Andy Clement
Resolution: Fixed  
Labels: @CompileStatic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows xp sp 3
java 1.6.0_20
groovy-eclipse-compiler 2.6.0-01
groovy 1.8.4
maven 3.0.2


Attachments: File generic_subclass_edgecase_source.tar    
Number of attachments : 1

 Description   

Used as part of maven build.

I am working with a legacy java application built with maven using the groovy-eclipse-compiler v2.6.0-01. We tend to use Groovy when enhancing the system or fixing defects.

I have run into a situation where a groovy class is extending a parametrized abstract Java superclass. The JVM throws a AbstractMethodError when executing the resulting groovy subclass. The class file for the groovy subclass does not include a method signature matching the generic abstract method defined in the Java superclass.

Here is a distilled example:

==Source==
public abstract class GenericSuper<T extends Number>

{ public abstract T someMethod(T arg); }

public class JavaSub extends GenericSuper<Long> {
@Override
public Long someMethod(Long someArg)

{ return someArg; }

}

class GroovySub extends GenericSuper<Long> {
@Override
Long someMethod(Long someArg)

{ someArg }

}

==Bytecode==
when running javap on the resulting GroovySub class:
Compiled from "GroovySub.groovy"
public class GroovySub extends GenericSuper implements groovy.lang.GroovyObject{

public static transient boolean __$stMC;
public GroovySub();
public java.lang.Long someMethod(java.lang.Long);
public java.lang.Object this$dist$invoke$2(java.lang.String, java.lang.Objec
t);
public void this$dist$set$2(java.lang.String, java.lang.Object);
public java.lang.Object this$dist$get$2(java.lang.String);
protected groovy.lang.MetaClass $getStaticMetaClass();
public groovy.lang.MetaClass getMetaClass();
public void setMetaClass(groovy.lang.MetaClass);
public java.lang.Object invokeMethod(java.lang.String, java.lang.Object);
public java.lang.Object getProperty(java.lang.String);
public void setProperty(java.lang.String, java.lang.Object);
public static void __$swapInit();
static {};
public java.lang.Object someMethod(java.lang.Object);
public void super$1$wait();
public java.lang.String super$1$toString();
public void super$1$wait(long, int);
public void super$1$notify();
public java.lang.Class super$1$getClass();
public void super$1$notifyAll();
public void super$1$finalize();
public void super$1$wait(long);
public boolean super$1$equals(java.lang.Object);
public java.lang.Object super$1$clone();
public int super$1$hashCode();
static java.lang.Class class$(java.lang.String);

Notice that there are two signatures for someMethod(). One with an Object and another with a Long.

when running javap on the resulting JavaSub class:
Compiled from "JavaSub.java"
public class JavaSub extends GenericSuper

{ public JavaSub(); public java.lang.Long someMethod(java.lang.Long); public java.lang.Number someMethod(java.lang.Number); }

There are also two signatures for someMethod(). However, one is for Long and the other is for the "Generic" Number.

When the GroovySub is compiled using groovyc v1.8.2 the someMethod() signatures are similar to the ones for JavaSub - Long & Number. So this problem appears to be a result of the eclipse groovy compiler.



 Comments   
Comment by Andrew Eisenberg [ 28/Dec/11 ]

Thanks for reporting and for providing a good test case.

I can reproduce the problematic byte code in Groovy-Eclipse without using maven, so this is a problem with our compiler integration. When compiling on the command line with groovyc, I see the expected signatures for someMethod.

Assigning to Andy, who has done the compiler integration work.





[GRECLIPSE-1305] Outline view filtering Created: 27/Dec/11  Updated: 03/Jan/12  Resolved: 03/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Minor
Reporter: Maxime HAMM Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: GroovyOutlinePage, outline
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File GroovyOutlinePage.java.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

I discover an issue using the Groovy outline view :
1) Edit some java file and apply some filtering stuff in the Outline view : Hide non-public members for example
2) Go to some Groovy file : for example a Jspresso DSL file
==> The outline details is filtered according to the Java filtering parameters

In fact all filtering actions were removed from the groovy outline view... but some filtering mecchanisum are style present...
Please find attached a patch that fix the problem
Regards
Maxime



 Comments   
Comment by Andrew Eisenberg [ 27/Dec/11 ]

So, this patch will remove the filters that are applied in Java files. A better approach would be to allow full filtering of Groovy files, of course. But, this is outside the scope of this issue. Any desire to look into this yourself?

Comment by Andrew Eisenberg [ 27/Dec/11 ]

Thanks for the patch. I've applied and committed it.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Should have been marked as fixed.





[GRECLIPSE-1304] String literal '$' is incorrectly underlined Created: 24/Dec/11  Updated: 27/Dec/11  Resolved: 27/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following code sample:

def s = '$'

Shows as def s = '$' in the editor



 Comments   
Comment by Andrew Eisenberg [ 25/Dec/11 ]

Problem here is that we are confusing '$' (a valid string) with "$" (a syntax error since it is an invalid GString).

Comment by Andrew Eisenberg [ 27/Dec/11 ]

Fixed with regression tests.





[GRECLIPSE-1303]  Filtering groovy completion proposal issue Created: 22/Dec/11  Updated: 24/Dec/11  Resolved: 24/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Minor
Reporter: Maxime HAMM Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: completon, dsl, eclipse, editor, groovy
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File org.codehaus.groovy.eclipse.workspace.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Hi

I think there is an issue using the " extension point :

The filtering algorithm using the extension point is part of class
"org.codehaus.groovy.eclipse.codeassist.processors.StatementAndExpressionCompletionProcessor"
:

        // extra filtering and sorting provided by third parties
        try {
            List<IProposalFilter> filters = ProposalProviderRegistry
                    .getRegistry().getFiltersFor(context.unit);
            for (IProposalFilter filter : filters) {
                try {
                    List<IGroovyProposal> newProposals = filter
                            .filterProposals(groovyProposals, context,
                                    getJavaContext());
                    groovyProposals = newProposals == null ? groovyProposals
                            : newProposals;
                } catch (Exception e) {
                    GroovyCore.logException(
                            "Exception when using third party proposal
filter: "
                                    + filter.getClass().getCanonicalName(),
e);
                }
            }
        } catch (CoreException e) {
            GroovyCore.logException(
                    "Exception accessing proposal provider registry", e);
        }

In fact there is today 9 different processor classes that inherits from
"AbstractGroovyCompletionProcessor"...
That is why some groovy completion are still visible even after filtering
using the extension point...

==>I send you one proposal that fix this... but the signature of
"IProposalFilter" is modified... this is fine for Jspresso... but it may impact
other third parties... I know this extension was created for Jspresso... then
may be we are the only third party that use it today ?
What do you think about it ?

==> In fact that will not fit completely my needs : I also need to filter
other proposals : native Java proposals... Can you may be inherit from
"ContentAssistProcessor" or "JavaCompletionProcessor" so that you could
override method "filterAndSortProposals"...
What do you think about it ?

==> Or may be we should ask eclipse.org to add a new "completion filtering
extension point"... or asking "javaCompletionProposalSorters" to include the
possibility of removing proposals...
What do you think about it ?

Thank you for reading this !

Regards
Maxime HAMM
www.jspresso.org



 Comments   
Comment by Andrew Eisenberg [ 22/Dec/11 ]

Unfortunately, at this point, we can't change the API. I know of others who are using this extension point and we can't break them. So, we can't change any signatures in IProposalFilter.

There are some solutions, but none of them are clean.

  1. Create IProposalFilterExtension interface with the new method signature that you need.
  2. Third-parties can optionally choose to implement this new interface.
  3. Keep the code in StatementAndExpressionCompletionProecessor the same
  4. Use the patch that you provided for GroovyCompletionProposalComputer, except add an instanceof test before calling the filterProposals method.

(This is a standard way of extending interfaces inside of the Eclipse framework. Not entirely clean, but at least it is structured.)

Your implementation would treat the original {{filterProposals]} as a no-op and do all the work in the new variant of the method.

We can then think about deprecating the original method, but I'm not sure we should.

If you do something like I suggest above, I'll take the patch. Also, please create a single patch from your workspace by selecting the changed projects right-click -> Team -> Create patch... And then choosing "Workspace" as the patch root.

Comment by Maxime HAMM [ 22/Dec/11 ]

New patch according to Andrew requirments (i hope so!)

Comment by Maxime HAMM [ 22/Dec/11 ]

Hi Andrew.
I think I do the job like you ask me to do... The patch is attached... It works fine for Jspresso
Let me know if this will be part of next snapshot/milestone/release
Maxime

Comment by Andrew Eisenberg [ 22/Dec/11 ]

Thanks for the patch. Looks reasonable. I applied it and will commit shortly. It will be available in the next day or so.

Comment by Maxime HAMM [ 23/Dec/11 ]

Hi
Don't you fotgot to submit new class "AnnotationAttributeCompletionProcessorFactory"... I can see a reference that points to it... but the class doesn't exists in the repository...
Maxime

Comment by Andrew Eisenberg [ 23/Dec/11 ]

Urrrgh...I committed something that should not have been committed. Should be fixed now.

Comment by Andrew Eisenberg [ 24/Dec/11 ]

Fixed. Compiles clean now.





[GRECLIPSE-1302] Right hand literal operand in binary expression is incorrectly underlined Created: 20/Dec/11  Updated: 20/Dec/11  Resolved: 20/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In all of the following expressions, the right hand argument is underlined:

1 > 1
1 < 1
1 >= 1
1 <= 1
1 <=> 1
1 == 1


 Comments   
Comment by Bob Tiernay [ 20/Dec/11 ]

Found using 2.6.1.xx-20111220-1500-e36

Comment by Andrew Eisenberg [ 20/Dec/11 ]

Probably a temporary regression as I have been doing a big refactoring of this area. I'll look into it.

Comment by Andrew Eisenberg [ 20/Dec/11 ]

Thanks for catching this. This was a regression introduced earlier today or yesterday. I didn't have any tests for this part. Now I do and it is fixed.





[GRECLIPSE-1301] ~enclosingCallName doesn't work if more than one enclosingCall Created: 20/Dec/11  Updated: 03/Jan/12  Resolved: 22/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Sample code:

foo {
  bar {
     here()
  }
}

Sample pointcut:
~enclosingCallName('foo')

The pointcut will match at the call to here(). But that seems illogical.
enclosingCallName('foo') should be true if there exists a enclosing call 'foo'.

This is true at 'here()'.

When we prefix a true expression with ~ it should become false... considering we are looking at the same point in the program (i.e. still the call to here())



 Comments   
Comment by Andrew Eisenberg [ 22/Dec/11 ]

So, just to get something concrete here. Given this dsld:

contribute(~ enclosingCallName("foo")) {
	property name:"hi"
}

and this script:

foo {
	bar {
		hi
	}
}

In this case. what would you expect? Should hi be underlined?

Comment by Andrew Eisenberg [ 22/Dec/11 ]

If you change the script to this:

contribtuu(enclosingCall(~name("foo"))).accept {
	property name:"hi"
}

Then hi is not underlined. The difference is as follows:

  • first variant returns true only if none of the enclosing call names are foo.
  • second variant returns true if there is at least one enclosing call whose name is not foo.

Maybe the first pointcut should be renamed to enclosingCallNames to indicate that it matches on more than just one call.

Comment by Andrew Eisenberg [ 22/Dec/11 ]

Resolving this issue because I think the current implementation is reasonable, except possibly for the name of enclosingCallName, but I don't think we will change that.

Adding some regression tests.

Comment by Kris De Volder [ 03/Jan/12 ]

I'm not going to argue... I think it just means I clearly don't understand the semantics of the pointcut language or the not pointcut.

Just a question...

In my intial example

Does enclosingCallName("foo") evaluate to true at the call to here?

(This question is to help me debug my understanding, maybe the answer is no... in which case it would indeed be logical if adding the ~ in front of it makes it true).

However if both ~enclosingCallName("foo") and enclosingCallName("foo") are true at the same point in the program (i.e. call to here, then I just can't make any sense of the semantics of the ~ operator).





[GRECLIPSE-1300] The type of - on collections looses element info Created: 20/Dec/11  Updated: 20/Dec/11  Resolved: 20/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
class Bingo {
	
	
	def foo() {
		def x = [ "a", "ab", "bc"]
		def z = x - x
	}

}

Type of z is List<Object>... should be List<String>

In general I think one shoul assume the elements to be of the same type as the elements in the first collection. Since you are removing elements from the list, so it can at most have the same elements as in the original collection.



 Comments   
Comment by Andrew Eisenberg [ 20/Dec/11 ]

This is one of the things I have been working on.

Comment by Andrew Eisenberg [ 20/Dec/11 ]

The problem here is that we don't do anything with type parameters on methods. And the minus method is declared using a type parameter.

I can work something special for this case, because it is common, but I need a more robust solution for method type parameters. See also GRECLIPSE-1129.

Comment by Andrew Eisenberg [ 20/Dec/11 ]

Fixed and committed with regression tests.

I special cased + and - on list types as well as on numbers and strings. For Strings, we have a hard time picking out the right variant from DefaultGroovyMethods. For lists, there is a type parameter on the plus and minus methods. And for numbers, they avoid dynamic dispatch altogether.





[GRECLIPSE-1298] Allow DSLD to define the 'delegate' type for a particular closure Created: 20/Dec/11  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GRECLIPSE-1323 Implement the closestEnclosingCallNam... Open
dependent
is depended upon by GRECLIPSE-1322 Update wiki documentation to include ... Open
Number of attachments : 0

 Description   

A common idiom in many a DSL (e.g. the Gradle DSL) is that we have

<keyword> {
}

For some keyword (e.g. repositories, dependencies, etc.). The keyword switches on some DSL feature inside of the closure block by setting the delegate of the closure.

It would be nice to directly support this kind of idiom. I first though that is what 'delegatesTo' did... but it doesn't.

Right now the 'delegate' is assumed to be the same as the 'receiver' of <keyword> method. That is often but not always correct.

A more complex use case in the Gradle DSLD is the 'configure' method.

configure(<something>) {
}

This will set the delegate in the closure not to some specific type, but to a type that is derived from <somethings> type. (E.g. <something> is a Project then the delegate will be that project. If something is a list of Project, it will be invoking the closure repeatedly for each project in the list.

This is probably hard/impossible to support, but at least we could support the more easy case where the delegate has a specific and well known type.



 Comments   
Comment by Bob Tiernay [ 02/Jan/12 ]

If you are trying to achieve something like grail's resources.groovy where you have single file that assigns a closure to a binding variable, the easiest way of "prescribing required methods/properties within a closure" is to simply use enclosingCallName("method"). You can use this in conjunction with fileName("my-file.groovy") to limit the scope of the pointcut.

One thing I find annoying is that, from what I understand, one cannot limit the call to the top-level scope of closure body. What this means is that if you have a structure like:

reports = { 
   report { 
      params { 
          param(...) 
      } 
   } 
} 

You cannot limit the applicability of the param call to the params body unless you do something like the following in your DSLD file:

 
// Base pointcuts 
def reportsFile = fileName("report-definitions.groovy") 
def reportsCall = enclosingClosure() 
def reportCall  = enclosingCallName("report") 
def paramsCall  = enclosingCallName("params") 

// Composite pointcuts 
def globalScope  = reportsFile & ~reportsCall & ~reportCall & ~paramsCall 
def reportsScope = reportsFile & reportsCall & ~reportCall & ~paramsCall 
def reportScope  = reportsFile & reportCall & ~paramsCall 
def paramsScope  = reportsFile & paramsCall 

As you can see, you have to exclude all other scopes to achieve the desired effect. It would be nice if there were a pointcut like enclosingScopeCallName that provided this capability since it is often what is required for builder-based DSLs.

Comment by Andrew Eisenberg [ 04/Jan/12 ]

Some initial success prototyping a solution for this. I should be able have a real implementation available soon.

Comment by Andrew Eisenberg [ 06/Jan/12 ]

Turns out my initial prototyping uncovered the problem described in GRECLIPSE-1318, which is now fixed. I am thinking of a bit of a different solution than what you are suggesting.

contribute(enclosingClosure() & enclosingCallName("report")) {
  setDelegateClass 'com.foo.MyClass'
}
contribute(enclosingCallName("params")) {
  setDelegateClass 'com.foo.MyOtherClass'
}

This will set the type of the closure's delegate field to com.foo.MyClass or whatever is specified.

Although you are asking for a more precise way to match inside of a closure, but not inner closures, this solution gives you a way to precisely specify the value of delegate inside of a given closure. This should be sufficient.

If you need to handle inner closures, then the simply take advantage of the fact that in dslds, contribution blocks are executed in lexical order. And so, if 2 pointcuts match and each one does a setDelegateType, the second one will always trump the first.

I am not committing anything yet, but this is my planned solution. Any comments?

Comment by Bob Tiernay [ 06/Jan/12 ]

Although useful, I don't know how practical this would be for builder-based dsls. For builder dsls, the delegate is often the same class in each scope, but for the purpose of the dsl calls must be restricted based on scope. With your proposal, one would have to create artificial classes to satisfy the dsl scope restriction requirement.

Comment by Bob Tiernay [ 06/Jan/12 ]

What is required is the DSLD equivalent of AspectJ's withincode(MethodPattern) pointcut. I would think this would be easy to implement in AST terms, but what do I know

Comment by Andrew Eisenberg [ 06/Jan/12 ]

I think what you are asking for is a variant of enclosingCallName that only looks at the closest call, something like closestEnclosingCallName (not sure if I like the name, though).

So:

contribute(closestEnclosingCallName("report")) {
  ...
}
report {
  // 1
  params {
    // 2
  }
}

So, this would match at 1, but not 2. However, this might be a problem because of this:

report {
  [list, of, reports].each {
     // do something reporty here
  }
}

I would expect that the contributions would have to work inside of the each closure. So, it's hard for me to see how you can specify the builder without being extremely specific.

Comment by Andrew Eisenberg [ 06/Jan/12 ]

OK. I committed some initial work on setDelegateType. This should help Kris's initial problem. This is still a bit untested and I want to know if it works for you, Kris, so we can work on this next week.

Bob, I'm beginning to think that your requirements are different enough that we should discuss this on a different issue. If I get a chance tonight, I'll raise a new issue.

Comment by Bob Tiernay [ 07/Jan/12 ]

I think you're right. My requirement is a bit different.

Your example does point out some edge cases exist. However, I don't think there would be a problem with the each call since the delegate would most certainly be the list and not the builder. Thus, I wouldn't expect the pointcut to match. Inside builders, it is more common to see a for/in loop so that the delegate is preserved to participate in pretended method / property resolution.

Comment by Kris De Volder [ 09/Jan/12 ]

It is hard for me to say off the bat if this will work. I think it will work for me, but I'll have to try it out and play with it a bit. I'll post back when I had a chance to do that.

Comment by Andrew Eisenberg [ 09/Jan/12 ]

Based on discussions with Kris, this appears to work for his case. I committed the change with regression tests.

I already updated the meta DSLD, so setDelegateType will not be underlined.

Still need to update docs on the wiki.

Comment by Andrew Eisenberg [ 09/Jan/12 ]

I created GRECLIPSE-1323. Bob, is something like this sufficient to address the problem you are having?





[GRECLIPSE-1297] When contributing a method 'foo()' when 'currentType(Bar)' shouldn't the foo method show up when whereever we contribute 'delegatesTo(Bar)' Created: 20/Dec/11  Updated: 16/Jan/12  Resolved: 16/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This would seem logical to me... however it could also be a 'bug' in my understanding rather than DSLD.



 Comments   
Comment by Andrew Eisenberg [ 06/Jan/12 ]

This will be addressed by the fix to GRECLIPSE-1298. The solution will not involve delegatesTo, but rather setDelegateType. Example dsld:

contribute( enclosingClosure() & enclosingCallName("foo") ) {
  setDelegateType "MyOtherClass"
}

contribute( currentType( "MyOtherClass" ) ) {
  property name: "newProp"
}

In this script:

class MyOtherClass { }
foo {
  newProp
}

newProp will be resolved to the property in MyOtherClass.

Comment by Andrew Eisenberg [ 06/Jan/12 ]

Just a bit of clarification on what is going on here.

delegatesTo simply adds all of the methods in the other type to the current type. The value of this or delegate is not changed in the current scope.

setDelegateType does exactly what is implied. The type of the delegate variable is set in the current scope. And all methods and properties (transitively) that the type responds to are available for inferencing.

There are a few caveats. In this case, order matters. Contribution blocks in a dsld script are executed lexically. And scripts are executed in classpath order (unless they are coming from source, in which case they are executed before the others, but in an unspecified order).

So, when there are multiple setDelegateTypes applicable at the same location, only the last one is used. In the following example, newProp is still correctly inferred:

contribute( enclosingClosure() & enclosingCallName("foo") ) {
  setDelegateType "String"
}
contribute( enclosingClosure() & enclosingCallName("foo") ) {
  setDelegateType "MyOtherClass"
}
contribute( currentType( "MyOtherClass" ) ) {
  property name: "newProp"
}

However, when rearranging the order, it is not:

contribute( enclosingClosure() & enclosingCallName("foo") ) {
  setDelegateType "String"
}
contribute( currentType( "MyOtherClass" ) ) {
  property name: "newProp"
}
contribute( enclosingClosure() & enclosingCallName("foo") ) {
  setDelegateType "MyOtherClass"
}

And like this:

contribute( enclosingClosure() & enclosingCallName("foo") ) {
  setDelegateType "MyOtherClass"
}
contribute( enclosingClosure() & enclosingCallName("foo") ) {
  setDelegateType "String"
}
contribute( currentType( "MyOtherClass" ) ) {
  property name: "newProp"
}
Comment by Kris De Volder [ 16/Jan/12 ]

I think we can close this issue 'Works as Designed'

Comment by Andrew Eisenberg [ 16/Jan/12 ]

Works as designed.





[GRECLIPSE-1295] DSLD suggstion for "isThisType" is wrong Created: 20/Dec/11  Updated: 22/Dec/11  Resolved: 22/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GRECLIPSE-1292 isThisType pointcut not correct in DSLD Resolved
Number of attachments : 0

 Description   

Open any DSLD file. Type "isThisType" and CTRL-SPACE. Suggestion will add an argument. However trying to actually use 'isThisType' with an argument will result in an error. The error states that isThisType shouldn't be used with arguments.



 Comments   
Comment by Andrew Eisenberg [ 22/Dec/11 ]

Yes. The problem is that we are comparing the current type to the enclosing type declaration. Rather, we should be comparing the current type to this type. the enclosing type declaration can be different from this when inside of a closure.

Easy fix to make. I think it is OK to change the semantics here. There already is another pointcut currentTypeIsEnclosingType, it has the same semantics as isThisType, but is deprecated. We should keep both pointcuts and provide them with different semantics.

Comment by Andrew Eisenberg [ 22/Dec/11 ]

Fixed with regression tests.





[GRECLIPSE-1293] Lombok fails to participate in Java source compilation Created: 18/Dec/11  Updated: 01/Apr/12  Resolved: 31/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Maven integration
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Major
Reporter: Steve Skrla Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: maven
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apache Maven 3.0.3 (r1075438; 2011-02-28 10:31:09-0700)
Java v1.6.0_29, vendor: Apple Inc.
Mac OS X 10.7.2


Attachments: Text File GRECLIPSE-1293-patch.txt     Text File GroovyEclipseCompiler.no-format.patch     Zip Archive test-project.zip    
Testcase included: yes
Number of attachments : 3

 Description   

The lombok annotation processor does not appear to participate in the java source compilation. The attached project functions in eclipse with m2e, but yields the following error when compiled with maven from the command line (or Run As > Maven Build... option).

parsing /Users/sskrla/Documents/workspaces/groovy-eclipse-lombok/groovy-eclipse-lombok-test/src/main/java/com/test/LombokDataClass.java - #1/1]
[reading java/lang/Object.class]
analyzing /Users/sskrla/Documents/workspaces/groovy-eclipse-lombok/groovy-eclipse-lombok-test/src/main/java/com/test/LombokDataClass.java - #1/1
[reading lombok/Data.class]
[reading lombok/package-info.class]
[reading java/lang/String.class]
completed /Users/sskrla/Documents/workspaces/groovy-eclipse-lombok/groovy-eclipse-lombok-test/src/main/java/com/test/LombokDataClass.java - #1/1
[1 unit compiled]
----------
1. ERROR in /Users/sskrla/Documents/workspaces/groovy-eclipse-lombok/groovy-eclipse-lombok-test/src/main/java/com/test/LombokDataClass.java (at line 5)
public @Data class LombokDataClass {
^^^^^^^^^^^^^^^
The blank final field a may not have been initialized
----------
2. ERROR in /Users/sskrla/Documents/workspaces/groovy-eclipse-lombok/groovy-eclipse-lombok-test/src/main/java/com/test/LombokDataClass.java (at line 5)
public @Data class LombokDataClass {
^^^^^^^^^^^^^^^
The blank final field b may not have been initialized



 Comments   
Comment by Steve Skrla [ 18/Dec/11 ]

Digging deeper it appears that Lombok does not function as an annotation processor for ECJ compilers. Instead it expect to be a javaagent. However running maven with the Lombok java agent yeilds additional errors.

1. ERROR in /Users/sskrla/Documents/workspaces/groovy-eclipse-lombok/groovy-eclipse-lombok-test/src/main/java/com/test/LombokDataClass.java (at line 0)
package com.test;
^
Internal compiler error: java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/lookup/ReferenceBinding at org.eclipse.jdt.internal.compiler.lookup.ClassScope.buildFieldsAndMethods(ClassScope.java)

Comment by Andrew Eisenberg [ 18/Dec/11 ]

Have you gotten this to work in a pure groovy project (ie- without using maven)? I am just wondering if Lombok and groovy are compatible at all.

Comment by Steve Skrla [ 19/Dec/11 ]

I sincerely hope not, I was hoping to introduce groovy into our software stack but an incompatibility like that would kill it pretty fast =(

Comment by Jason Clawson [ 19/Dec/11 ]

I have patched this issue in a custom implementation of the groovy-eclipse-compiler. Its actually quite simple:

In the method compileOutOfProcess() I added a new command line argument to "cli" specifying a javaagent. I added the following method to discover the lombok jar location in helping figure this location out:

	private String getLombokLocation() throws CompilerException {
		Class<?> cls;
		try {
			cls = Class.forName("lombok.Lombok");
		} catch (ClassNotFoundException e1) {
			return null;
		}

		ProtectionDomain pDomain = cls.getProtectionDomain();
		CodeSource cSource = pDomain.getCodeSource();
		if (cSource != null) {
			URL loc = cSource.getLocation();
			File file;
			try {
				file = new File(URLDecoder.decode(loc.getPath(), "UTF-8"));
			} catch (UnsupportedEncodingException e) {
				getLogger().warn("Unsupported Encoding for URL: " + loc, e);
				file = new File(loc.getPath());
			}
			return file.getPath();
		} else {
			throw new CompilerException(
					"Cannot find the location of the lombok jar");
		}
	}

I also included lombok as a dependency to the maven-compiler-plugin. Can I suggest a way to make this more generic and have it implemented by you guys?

Add a new configuration argument for the groovy-eclipse-compiler. Call it something like "javaAgentClass" or something. Auto-discover the jar using the method like I posted above and include it as a -javaagent argument to java.

Thanks!

Comment by Andrew Eisenberg [ 19/Dec/11 ]

Thanks, Jason. This seems like a reasonable fix.

So presumably, if lombok.jar is on the classpath of the maven-compiler-plugin, then the class will be loadable inside of getLombokLocation(). But, what does this extra command line argument look like?

And any desire to package this up as a proper patch, so I can add it to the source tree? Making this more general than just lombok would be the way to go.

Comment by Christophe Furmaniak [ 30/Mar/12 ]

I think the command is just something like

-javaagent:${path/to/}lombok.jar

, because it's the way that lombok IDE installer configures Eclipse or Netbeans.

Comment by Christophe Furmaniak [ 31/Mar/12 ]

I'm trying to produce a patch to fix this issue, following the suggestion of Jason Clawson to add an extra param to the plugin, but I am hitting the fact that it does not seem easy to extend maven AbstractCompiler and use an extra param (javaAgentClass in our case).
Although the explanation given at http://blog.aggregat4.net/extending-existing-maven-2-plugins-is-harder is Maven 2 related, I think it is still a effective for maven 3.

Would you have any hint on how you would achieve that?

I could make the plugin work with a hardcoded javaAgentClass param, when a forked compilation is requested by patching compileOutOfProcess.

Next step is to pass the javaagent stuff to the org.eclipse.jdt.internal.compiler.batch.Main for non-forked compilation. Any tip on this step will be helpfull too

Comment by Christophe Furmaniak [ 31/Mar/12 ]

Ok, forget about the "extend the maven-compiler stuff", the groovy eclipse compiler does not extend maven-compiler.
I passed the extra param using compilerArguments.

Next step, make it work when fork=false if it is possible.

Comment by Christophe Furmaniak [ 31/Mar/12 ]

According to http://groups.google.com/group/project-lombok/browse_thread/thread/3f78910a6a10e3c3 and http://code.google.com/p/projectlombok/issues/detail?id=212 I'm not sure it can be done with fork=false

Comment by Christophe Furmaniak [ 31/Mar/12 ]

Please find attached a patch that propose a new compilerArguments name javaAgentClass that is taken into account when fork=true.

The patch contains a lot of diff because of formating changes (sorry, I am a compulsive source code formatter in Eclipse).

I you provide me the rules of formatting used on the project I can give you a smaller patch.

Comment by Christophe Furmaniak [ 31/Mar/12 ]

Here is the patch

Comment by Christophe Furmaniak [ 31/Mar/12 ]

I forgot to mention that you need to customise your pom like this:

<configuration>
    <compilerId>groovy-eclipse-compiler</compilerId>
	<verbose>true</verbose>
	<fork>true</fork>					
	<compilerArguments>
        	<javaAgentClass>lombok.core.Agent</javaAgentClass>
	</compilerArguments>
</configuration>
Comment by Andrew Eisenberg [ 31/Mar/12 ]

Thanks for the patch, but it is not a valid patch file and does not apply. Can you recreate the patch from within Eclipse?

I added formatting preferences to the project. Please check the project out and use the included formatting preferences to format the project. Make the patch as small as possible and use as few white space changes as possible.

Comment by Christophe Furmaniak [ 31/Mar/12 ]

Please find a patch that should work better.

Comment by Andrew Eisenberg [ 31/Mar/12 ]

Got the patch and tried it on the test project attached to this issue. In addition to the configuration that you have above, you also need to add lombok both as a build and a compile dependency.

This patch looks good and I'll accept it. I'll also take the attached project as an integration test.

Comment by Andrew Eisenberg [ 31/Mar/12 ]

All tests pass. I am publishing a new 2.6.1-01-SNAPSHOT. This should be working for you. Let me know if you have any trouble.

Comment by Christophe Furmaniak [ 01/Apr/12 ]

Thanks for applying the patch; and yes, I forgot to mention the "add lombok as a build dependency" (mea culpa, again)

The needed pom configuration is then something like that (adjust your versions if needed)

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.1</version>
    <configuration>
    <compilerId>groovy-eclipse-compiler</compilerId>
    <verbose>true</verbose> 
    <fork>true</fork>   
    <compilerArguments>
        <javaAgentClass>lombok.core.Agent</javaAgentClass>
    </compilerArguments>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.6.1-01-SNAPSHOT</version>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>0.11.0</version>
        </dependency>
    </dependencies>
</plugin>

Works for me with latest snapshot.





[GRECLIPSE-1292] isThisType pointcut not correct in DSLD Created: 16/Dec/11  Updated: 22/Dec/11  Resolved: 22/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GRECLIPSE-1295 DSLD suggstion for "isThisType" is wrong Resolved
Number of attachments : 0

 Description   

The isThisType pointcut compares the enclosingType to the currentType and returns true if they are the same. However, this is not always the expected behavior. Consider this:

class Other {
  def method(Closure c) { ... }
}
class Foo {
  def method() {
    new Other().method {
      xxx
    }
  }
}

I would expect that isThisType would return true when evaluating xxx, but it is not. The declaring type inside of the closure of method, is Other, and the enclosing type is Foo.

On the other hand, perhaps isThisType is appropriately named and behaving, but we need a different pointcut that will match on xxx, where there is no '.' in the expression.






[GRECLIPSE-1291] Inferring the type of overloaded unary operators Created: 16/Dec/11  Updated: 20/Dec/11  Resolved: 20/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The inferencing engine should check for overloaded operators when determining the inferred types of operators. Eg, when using '+', the inferencing engine should infer the type of the plus method on the target type.

Also, methods contributed through a dsld should be used to infer operator overloading.

This issue is specifically about unary operators which must be treated differently from binary operators.



 Comments   
Comment by Andrew Eisenberg [ 20/Dec/11 ]

Now available.





[GRECLIPSE-1290] Inferring the type of overloaded binary operators Created: 16/Dec/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes GRECLIPSE-1081 Operator overloading should be config... Resolved
Number of attachments : 0

 Description   

The inferencing engine should check for overloaded operators when determining the inferred types of operators. Eg, when using '+', the inferencing engine should infer the type of the plus method on the target type.

Also, methods contributed through a dsld should be used to infer operator overloading.



 Comments   
Comment by Andrew Eisenberg [ 16/Dec/11 ]

Mostly implemented and tested. The only piece left is to write tests for the dsld support on this.

Comment by Andrew Eisenberg [ 17/Dec/11 ]

Fix committed with regression tests.





[GRECLIPSE-1289] Weird behavior with method resolution within list index and following postincrement operator Created: 14/Dec/11  Updated: 26/Jan/12  Resolved: 26/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following code, the method invocation is not resolving in the editor (F3 / Open Declaration), which breaks refactoring of closure argument:

def method(obj) {
    obj
}

def list = [0,1]
[0,1].each { value ->
    list[method(value)]++
}


 Comments   
Comment by Andrew Eisenberg [ 15/Dec/11 ]

I'm not sure what the problematic behavior is here. I can properly rename method, list, and value. Hovers and navigation work as expected. What version of groovy are you using?

Comment by Bob Tiernay [ 17/Dec/11 ]

I'm currently using 2.6.1.xx-20111216-1200-e36 on Eclipse 3.6

The problem evinces when trying to rename the value variable. I have restarted the workspace and have performed a project clean. Also, renaming method also fails with:

Cannot refactor on current selection. No refactoring candidates found.
Comment by Bob Tiernay [ 17/Dec/11 ]

A more simpler example that shows the same behavior is the following script:

int i = 0
def list = [0]
list[i]++

In this example, F3 doesn't work on i. Also, attempting to refactor rename i fails with the same error as above.

Comment by Bob Tiernay [ 17/Dec/11 ]

I should clarify that I was attempting to rename in the last statement. If I rename in the first statement, the first statement is renamed but the last statement does not.

Comment by Bob Tiernay [ 27/Dec/11 ]

Andrew, I wasn't sure if you could reproduce this. Let me know if you need more information.

Thanks.

Comment by Andrew Eisenberg [ 06/Jan/12 ]

Got around to trying this and I can reproduce the problem. I'll have a look tomorrow.

Comment by Andrew Eisenberg [ 06/Jan/12 ]

I spoke too soon. The problem I was seeing was different. It was a regression that I introduced into the code from a refactoring I did a few days ago and not related to the problem you are describing.

Hmmm...I see that you are using E36. I have been trying this on E37. I'll see if behavior changes on E36.

Comment by Andrew Eisenberg [ 06/Jan/12 ]

This is not an E36/E37 issue, but a groovy 1.7 and groovy 1.8 issue. I'm going to add a test case for this that will run both in the 1.7 stream and 1.8 stream. It's likely that there's something about the AST in Groovy 1.7 that is broken in this situation. Since 1.8 has been released for over 6 months now, I do not think we will fix this, but good to know about.

Comment by Andrew Eisenberg [ 26/Jan/12 ]

As mentioned, since this is a 1.7-only issue, we won't be fixing this.





[GRECLIPSE-1288] Change package declaration quickfix Created: 13/Dec/11  Updated: 13/Dec/11  Resolved: 13/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When package declaration is incorrect in a groovy file, should be able to invoke the "Change package declaration" quickfix.



 Comments   
Comment by Andrew Eisenberg [ 13/Dec/11 ]

Already available in 2.6.1.





[GRECLIPSE-1287] Move package quick fix Created: 13/Dec/11  Updated: 13/Dec/11  Resolved: 13/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If groovy file has an incorrect package declaration, should be able to invoke "Move to new package" quick fix.



 Comments   
Comment by Andrew Eisenberg [ 13/Dec/11 ]

Already available in 2.6.1.





[GRECLIPSE-1286] Quick fixes and refactoring suggestions for 2.6.1 Created: 13/Dec/11  Updated: 26/Jan/12  Resolved: 26/Jan/12

Status: Closed
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.6.0.Release
Fix Version/s: 2.6.1.Release

Type: Epic Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the 2.6.1 release, we are going to be working on enhanced refactoring and quick assists. What would you most like to see? Please add your suggestions in a comment or in a sub-task.



 Comments   
Comment by Andrew Eisenberg [ 26/Jan/12 ]

We've discussed quick fixes and refactoring enough. And many new bugs have been raised for it. Closing this issue.





[GRECLIPSE-1284] ConcurrentModificationException during: "Refresh DSLD scripts" Created: 12/Dec/11  Updated: 11/Jan/12  Resolved: 11/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When I start Eclipse and the IDE does its initialization jobs, I often get the following exception:

java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
	at java.util.HashMap$EntryIterator.next(Unknown Source)
	at java.util.HashMap$EntryIterator.next(Unknown Source)
	at org.eclipse.jdt.internal.core.JavaModelManager$9.run(JavaModelManager.java:2796)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2816)
	at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1873)
	at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2798)
	at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2679)
	at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2843)
	at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1948)
	at org.eclipse.jdt.internal.core.JavaProject.buildStructure(JavaProject.java:463)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:518)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
	at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:196)
	at org.eclipse.jdt.internal.core.JavaProject.getPackageFragmentRoots(JavaProject.java:1836)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findDSLDsInLibraries(RefreshDSLDJob.java:99)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findFiles(RefreshDSLDJob.java:89)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.refreshProject(RefreshDSLDJob.java:279)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:227)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Last time it occured after the Gradle STS Integration plugin finished to refresh project dependencies.



 Comments   
Comment by Andrew Eisenberg [ 04/Jan/12 ]

I am fairly certain that this is happening because while DLSD files are being refreshed, the JDT classpath containers are being initialized. We need to wait to make sure that all classpath containers are initialized before trying to compile the DSLD scripts.

Comment by Andrew Eisenberg [ 04/Jan/12 ]

I committed a fix that probably avoids the concurrent modification exception. It will be available in the next snapshot build. If you get a chance, can you try it out and let me know if you still see the exception?

Comment by Mauro Molinari [ 05/Jan/12 ]

Hi Andrew, I can certainly try it. I will need some time though to check, since the problem was not always happening.

When the snapshot is supposed to be available? It should be available at http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/, shouldn't it?

Comment by Andrew Eisenberg [ 05/Jan/12 ]

Yes. It should be available from that update site now.

Comment by Mauro Molinari [ 10/Jan/12 ]

I've installed it. I now see the "Refresh DLD scripts" operation often wait for other operations related to the building of the workspace to finish. Let me test this for some days to see if the problem I reported rises again.

Thank you meanwhile!

Comment by Andrew Eisenberg [ 10/Jan/12 ]

Thanks for the feedback. My concern is that now it will take significantly longer to refresh the DSLD scripts because the refreshing has to wait until all builds are complete before running. Unfortunately, this is necessary since simply accessing the build path of a project seems to require a workspace-wide lock.

Just let me know how things work for you.

Comment by Mauro Molinari [ 11/Jan/12 ]

Isn't a lock on the involved project enough? Or, at least, a lock on the involved project and any dependant projects...

Comment by Andrew Eisenberg [ 11/Jan/12 ]

Unfortunately, no. What's happening is this.

The first time any classpath container is accessed, all classpath containers throughout the system are initialized (have you ever noticed the messages "Initializing Java Tooling", and "Configuring classpath containers" in the progress view? That is one of the jobs that is happening. These jobs are "lazy" in that they will not be executed until there is something that triggers the need for Java tooling. Typically, this happens early enough after startup that you don't realize it.

However, the hook for refreshing dslds sometimes happens early enough that it is the trigger for initializing Java tooling. In order to properly initialize Java tooling, you need to grab a workspace-wide lock. This is likely a JDT bug, but it has been around for so long and would be so difficult to change that it is something we need to work around, rather than fix.

Grabbing a workspace wide lock is bad because it means that virtually any other interesting action must wait until the lock is released in order to start (eg- saving, opening editors, building...).

What I have done is made the time where the workspace-wide lock is grabbed be as short as possible. This means that if Java tooling is already initialized, the lock will only be grabbed for a fraction of a second. If Java tooling is not initialized, then it will be significantly longer (but that is basically unavoidable).

The reason why this bug was originally so confusing to me is that typically, you only need to grab a lock if you are writing to the state, but this job is only reading from the state (or so I thought). It turns out that the refresh dsld job was writing to the state if it implicitly invoked Java tooling initialization.

Hope this makes sense to you.

Comment by Mauro Molinari [ 11/Jan/12 ]

Yes, you've been very clear. Thank you Andrew!
For me, you can close this bug. If the problem will arise again, I'll notify you and reopen it.

Comment by Andrew Eisenberg [ 11/Jan/12 ]

Closing, but comment here if you see the problem again.





[GRECLIPSE-1283] Extract Local Variable refactoring does not work when there is trailing whitespace after a method call expression Created: 11/Dec/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser, Refactoring
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following code (notice the trailing whitespace):

model.farInstance()  //

Extract local variable is not able to be performed. The trailing whitespace is included in the sloc of the method call expression. If the trailing whitespace is included, then extract local can successfully occur. But, whether or not whitespace is selected should be independent of whether or not the refactoring can be performed.



 Comments   
Comment by Andrew Eisenberg [ 15/Dec/11 ]

Fixed a few problems with Local variable extraction. Committed with regression tests.





[GRECLIPSE-1282] "Extract Method" with ALT+SHIFT+M doesn't work Created: 11/Dec/11  Updated: 18/Jan/12  Resolved: 11/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.04


Number of attachments : 0

 Description   

In the Java editor, ALT+SHIFT+M is often used to create a new method from selected text. This key binding doesn't seem to be applied in the Groovy editor.



 Comments   
Comment by Andrew Eisenberg [ 11/Dec/11 ]

Interesting. I know this used to work, but this is the kind of thing that we don't have any tests for. The reason why this is broken is because of the way that we have to hook into the JavaEditor. The JavaEditor hard codes certain actions that would normally be specified in the plugin.xml. Extract method is specified in both the plugin.xml and in the GroovyEditor (overriding the JavaEditor's behavior. By removing the key binding in the plugin.xml, I was able to get things working.

Comment by Andrew Eisenberg [ 11/Dec/11 ]

Fix committed. This will make it into the 2.6.0 release. The final build will be on Monday. Thanks for reporting the problem.





[GRECLIPSE-1280] no code assist on method call after comma Created: 10/Dec/11  Updated: 10/Dec/11  Resolved: 10/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Follow on from GRECLIPSE 1192 related to trailing commas. Here there is no suggestion of 'param' proposed:

class Bar {
	def param = 4
	def m()  {
		foo('abc',<Ctrl+Space>
	}
}


 Comments   
Comment by Andrew Eisenberg [ 10/Dec/11 ]

This is expected behavior. When invoking content assist at this location, you should only see method context proposals. These are the proposals that show the information about the method call you are in. (Also, named argument proposals would be available, but there are none at this location.)

You need a non-0 lengthed prefix in order to get any other kinds of proposals.

This is following the behavior of JDT content assist.





[GRECLIPSE-1278] NPE thrown from ConvertToClosureCompletionProposal when accessing Content Assist Created: 09/Dec/11  Updated: 18/Jan/12  Resolved: 09/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Critical
Reporter: Reuben Garrett Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: exception
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File GRECLIPSE_2011-12-09_eclipse-config.txt     Text File GRECLIPSE_2011-12-09_stack-trace.txt    
Number of attachments : 2

 Description   

When accessing Quick Assist within a Java editor, a NullPointerException is thrown and prevents Quick Assist from being accessed.



 Comments   
Comment by Andrew Eisenberg [ 09/Dec/11 ]

Thanks for the bug report and stack traces. Groovy-Eclipse should not be affecting your Java files. I am bumping up the severity.

Comment by Andrew Eisenberg [ 09/Dec/11 ]

Fixed

Comment by Reuben Garrett [ 09/Dec/11 ]

Thanks, Andrew! I apologize for the mis-categorization. I thought I had 2.6.0 installed based on what I saw in my Eclipse config. Did I somehow have an older version mixed in as well?

Comment by Andrew Eisenberg [ 09/Dec/11 ]

No. You have a snapshot version of 2.6.0 installed. We will be releasing 2.6.0 final next week. The Affects version box always refers to the latest release even if you are using a snapshot of an unreleased version (unless the bug really is specific to an older version). These fields are for our own purposes primarily and we don't expect users to fill them in properly.





[GRECLIPSE-1276] Wrong indentation after return Created: 07/Dec/11  Updated: 22/Jan/12  Resolved: 22/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Formatting
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Follow up to GRECLIPSE-746. I have another use case where "return" causes a wrong indentation. Consider the following:

package test

class MyTestClass {
	static String myString = 'ciao'
	public static String main(String[] args) {
		def c,d,e,f,g,h,i,k
[1]		c.d(
				e.f(g.h(i.k)))
[2]		return c.d(
		e.f(g.h(i.k)))
	}
}

Look at the lines where c.d(e.f(g.h(i.k))) is called. I want to put a newline after c.d(. If I do it at [1] the indentation of the second line is correct. If I do it at [2], the "return" keyword makes the second line be wrongly indented, with "e" aligned to "return".
I'm using GRECLIPSE 2.5.2.xx-20110929-1800-e37.



 Comments   
Comment by Andrew Eisenberg [ 22/Jan/12 ]

Appears to be fixed now.





[GRECLIPSE-1275] NullPointerException in SuggestionCompilationUnitHelper.java:87 Created: 07/Dec/11  Updated: 07/Dec/11  Resolved: 07/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support, User Interface
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Mauro Molinari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I often get the following error, while working in Eclipse, but I don't have the steps to repro. I think the last time I was just deactivating a Mylyn Task, so that all the editor were closed, although the stack trace seems to be about code completion proposals:

java.lang.NullPointerException
	at org.codehaus.groovy.eclipse.dsl.inferencing.suggestions.SuggestionCompilationUnitHelper.findValidASTNode(SuggestionCompilationUnitHelper.java:87)
	at org.codehaus.groovy.eclipse.dsl.inferencing.suggestions.SuggestionCompilationUnitHelper.canAddSuggestion(SuggestionCompilationUnitHelper.java:75)
	at org.codehaus.groovy.eclipse.quickassist.AddSuggestionsQuickAssistProposal.hasProposals(AddSuggestionsQuickAssistProposal.java:69)
	at org.codehaus.groovy.eclipse.quickassist.GroovyQuickAssist.hasAssists(GroovyQuickAssist.java:34)
	at org.codehaus.groovy.eclipse.quickassist.GroovyQuickAssist.getAssists(GroovyQuickAssist.java:41)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeAssistCollector.safeRun(JavaCorrectionProcessor.java:403)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionProcessorAccess.run(JavaCorrectionProcessor.java:339)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionProcessorAccess.process(JavaCorrectionProcessor.java:329)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.collectAssists(JavaCorrectionProcessor.java:509)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.collectProposals(JavaCorrectionProcessor.java:287)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.computeQuickAssistProposals(JavaCorrectionProcessor.java:242)
	at org.eclipse.jface.text.quickassist.QuickAssistAssistant$ContentAssistProcessor.computeCompletionProposals(QuickAssistAssistant.java:75)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1830)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:488)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482)
	at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1656)
	at org.eclipse.jface.text.quickassist.QuickAssistAssistant.showPossibleQuickAssists(QuickAssistAssistant.java:128)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionAssistant.showPossibleQuickAssists(JavaCorrectionAssistant.java:193)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:195)
	at org.eclipse.ui.texteditor.TextOperationAction$1.run(TextOperationAction.java:128)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.texteditor.TextOperationAction.run(TextOperationAction.java:126)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185)
	at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
	at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
	at org.eclipse.swt.widgets.Widget.wmKeyDown(Widget.java:1809)
	at org.eclipse.swt.widgets.Control.WM_KEYDOWN(Control.java:4892)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4560)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2531)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)


 Comments   
Comment by Andrew Eisenberg [ 07/Dec/11 ]

Thanks for the bug report. Added an appropriate guard to avoid the NPE. Fixed and committed.





[GRECLIPSE-1274] Non-static DelegatesTo methods should not be available in static scope Created: 06/Dec/11  Updated: 06/Dec/11  Resolved: 06/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: None
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Originally posted as https://issuetracker.springsource.com/browse/STS-2317.

This DSLD snippet delegates all methods defined in List to whatever the current type is:

delegatesTo List

However, if the current scope is static (ie- a class object), then the inferencing and content assist still assumes the delegation occurs, even though it shouldn't.



 Comments   
Comment by Andrew Eisenberg [ 06/Dec/11 ]

Fix is now committed.





[GRECLIPSE-1272] Date methods next, plus, and format are indicated as deprecated in the editor but shouldn't be Created: 04/Dec/11  Updated: 06/Dec/11  Resolved: 06/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following method calls are semantically marked as deprecated although they shouldn't be:

Date date = new Date()
date.next()
date.plus(1)
date.format("yyyy")


 Comments   
Comment by Bob Tiernay [ 04/Dec/11 ]

This is also true of:

"DEADBEEF".decodeBase64()

I guess this is a general issue where DGM methods have been deprecated and moved to specialized classes. Ideally if a DGM method is deprecated and another method exists elsewhere, there would be no error. Not sure how easy this is to do without hard coding exceptions into the plugin. But I suppose this wouldn't be the first time .

Comment by Bob Tiernay [ 04/Dec/11 ]

After reading GRECLIPSE-1158, it might not be possible (or required) to fix this issue.

Comment by Andrew Eisenberg [ 06/Dec/11 ]

I won't be fixing this since it is not relevant for 1.8 and later.





[GRECLIPSE-1270] IndexOutOfBoundsException with assert keyword in Spock test Created: 02/Dec/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Minor
Reporter: Erik Forkalsrud Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.8.1.RELEASE


Attachments: Text File stack.txt    
Issue Links:
Related
relates to GROOVY-5197 Source location incorrect for stateme... Closed
Number of attachments : 1

 Description   

My superficial search for any existing reports didn't yield any results, but if this is already a know issue I apologize.

I ran into a Spock test that looks like this:

    import spock.lang.Specification

    class CompilerTest extends Specification {
        def "minimal test case"() {
            given:
                i = 1
            when:
                i++
            then:
                assert i == 2
        }
    }

Although the "assert" keyword in the then-clause is not necessary, I believe it's valid code.
However, the code above causes a java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 ...
at org.codehaus.groovy.transform.powerassert.SourceText.getNormalizedColumn(SourceText.java:103)
(I'll attache the full stack trace later.)

There are two ways to work around it:

  1. remove the "assert" keyword (so it becomes "then: i == 2")
  2. add code between "then:" and "assert", e.g "then: int expected = 2; assert i == expected"


 Comments   
Comment by Erik Forkalsrud [ 02/Dec/11 ]

Oops, my code example was mangled ... retry:

CompilerTest.groovy
import spock.lang.Specification

class CompilerTest extends Specification {
  def "minimal test case"() {
    given:
      i = 1
    when:
      i++
    then:
      assert i == 2
  }
}
Comment by Andrew Eisenberg [ 02/Dec/11 ]

What version of Spock? Using Groovy 1.7 or 1.8?

Comment by Erik Forkalsrud [ 07/Dec/11 ]

Groovy 1.7
Spock 0.4

Comment by Andrew Eisenberg [ 15/Dec/11 ]

Looks like there is a problem with source locations and this is not really a spock issue. I was able to reproduce the exception with this simple code:

def meth() {
  label:
    assert i == 9
}

In Groovy 1.7.x, the exception was being thrown because the line number of the assert statement is incorrect. It is being set to the line number of label. In Groovy 1.8.x, the source locations are still incorrect, but no exception is being thrown.

I'm going to dig a bit deeper to see exactly why this is happening and if I can reproduce this in groovyc on the command line.

Comment by Andrew Eisenberg [ 15/Dec/11 ]

Yes. The source locations are incorrect in groovyc as well, but for some reason they are not tripped up over it as we are in Groovy-Eclipse.

I know how to fix it in Groovy-Eclipse and I will raise a Groovy bug so they can take the change.

Comment by Andrew Eisenberg [ 15/Dec/11 ]

Committed fix with regression test. Hopefully, the fix can make it into groovy core as well.





[GRECLIPSE-1269] Support annotation processor for batch compiler Created: 01/Dec/11  Updated: 12/Dec/11  Resolved: 12/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Maven integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Major
Reporter: Renato Garcia Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File GRECLIPSE-1269.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Currently the annotation processing/jsr269 is supported inside eclipse using Groovy classes, however this functionality is not available when using the batch compiler.

For more details please refer to the discussion.
http://markmail.org/thread/lyshsfwhierikxw4



 Comments   
Comment by Andrew Eisenberg [ 01/Dec/11 ]

I think this is a packaging problem where we don't package the apt library with the batch compiler.

Comment by Renato Garcia [ 06/Dec/11 ]

Patch to include apt library attached. With this patch the compiler calls the processors.

Comment by Andrew Eisenberg [ 06/Dec/11 ]

Thanks for the patch. This seems reasonable to me. From your comment, it seems that you have tried this and it is working for you. Is that right?

Comment by Renato Garcia [ 06/Dec/11 ]

Yep, I tested it with the same classes from the discussion thread.

There are other plugins related to APT but I've choosen the ones to include based on ecj-3.7.1.jar, so the APT classes match exactly, except from the file: compiler_apt_fragment.properties on the groovy-eclipse-batch, but it don't seem to interfere.

Just for the record, I got an issue when trying to compile classes inside packages, but I think this is not related to the changes since it was happening before changes as well and with simple classes not related to APT. So I just removed the test classes from the package and it worked fined. The error I get when trying to compile classes inside package is:

java.lang.IllegalStateException: Workspace is closed.
	at org.eclipse.core.resources.ResourcesPlugin.getWorkspace(ResourcesPlugin.java:399)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.dietParse(GroovyParser.java:427)
	at org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.dietParse(MultiplexingParser.java:44)
	at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:773)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:393)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:479)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:3783)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1679)
	at org.eclipse.jdt.internal.compiler.batch.Main.main(Main.java:1392)
Workspace is closed.
Comment by Andrew Eisenberg [ 06/Dec/11 ]

Interesting...yes. That is unrelated to the change that you made. It is something that we had to put in to support some grails AST transforms, so it is irrelevant for what you are doing. The exception comes about because a call is being made that requires an actual workspace (not present during batch compilation).

We can guard against this happening, but really we need to be more careful in the future.

Comment by Andrew Eisenberg [ 06/Dec/11 ]

Best way to guard is to call ResourcesPlugin.getPlugin() == null. If true, then workspace is closed.

Comment by Andrew Eisenberg [ 06/Dec/11 ]

Fix for exception has been committed. The 2.6.0 release is coming out in the next week. Once the release it out, I will recreate the maven artifacts.

Comment by Andrew Eisenberg [ 08/Dec/11 ]

I just deployed new groovy-eclipse-batch artifacts for both 1.7 and 1.8. The versions to use are 1.8.4-01 or 1.7.10-6. The 1.8 version should be picked up by default.

These artifacts include the apt jar as you have in your patch. Please try this when you get a chance and let me know if it is working for you.

Comment by Andrew Eisenberg [ 12/Dec/11 ]

Fix is now available.

Comment by Renato Garcia [ 12/Dec/11 ]

Thanks! I tested with the released jar for 1.8 and it works for both, command line and maven compiler plugin.





[GRECLIPSE-1267] Content assist for implicit owner and delegate properties inside closure Created: 27/Nov/11  Updated: 30/Nov/11  Resolved: 29/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following should support content assist in the editor:

def c = {
    owner // content assist for implicit owner property
    delegate // content assist for implicit delegate property
}


 Comments   
Comment by Andrew Eisenberg [ 29/Nov/11 ]

Should be simple enough to fix.

Comment by Andrew Eisenberg [ 29/Nov/11 ]

Committed fix with regression tests.

Comment by Bob Tiernay [ 30/Nov/11 ]

Great work Andrew! Thanks for this

Some other, less often used, but still useful Closure properties are demonstrated below:

def f = { int x -> println thisObject; println resolveStrategy; println directive; println parameterTypes; println maximumNumberOfParameters}

It would be nice if these were available, but they aren't as useful as delegate and owner





[GRECLIPSE-1266] Unable to resolve delegate method from parent class inside closure Created: 27/Nov/11  Updated: 18/Jan/12  Resolved: 28/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following code snippet the editor underlines the call to group(it):

class P {
    protected group(int value) {
        value
    }
}

class C extends P {
    def method() {
        [1,2,3].groupBy { group(it) }
    }
}


 Comments   
Comment by Andrew Eisenberg [ 28/Nov/11 ]

Duplicate of GRECLIPSE-1265.





[GRECLIPSE-1264] Missing underline when setting missing property Created: 27/Nov/11  Updated: 18/Jan/12  Resolved: 28/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Aled Sage Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Number of attachments : 0

 Description   

I attempted to set a non-existant property (see code below).

I expected this to be underlined in my Eclipse editor, but it wasn't.

class SettingUndeclaredProperty {
    public void mymethod() {
        doesNotExist = "abc"
    }
}

When executed, it gives the error you'd expect:

    Exception in thread "main" groovy.lang.MissingPropertyException: No such property: doesNotExist for class: unresolvedvariablenotunderlined.SettingUndeclaredProperty

Note that reading the property value does give the correct underlining:

   String s = doesNotExist


 Comments   
Comment by Aled Sage [ 27/Nov/11 ]

Oops, didn't mean for this to be priority "major" but not sure if I have permissions to change that after submitting?

Comment by Andrew Eisenberg [ 27/Nov/11 ]

Looks like this regression has come about since I added support for this inside of scripts. This statement does not cause any runtime exceptions in a script:

doesNotExist = "abc"

but does inside of a regular method.

Comment by Andrew Eisenberg [ 28/Nov/11 ]

OK. Fixed locally. Need to write up a few tests and will commit.

Comment by Andrew Eisenberg [ 28/Nov/11 ]

fixed with regression tests.





[GRECLIPSE-1263] Are enums broken on the e36 version of the 2.5.2 release? Created: 25/Nov/11  Updated: 26/Jan/12  Resolved: 26/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Note from mailing list that using an enum in the e36 variant of 2.5.2 release is causing compile problems:

Groovy:The class java.lang.Enum refers to the class java.lang.Enum and uses 1 parameters, but the referred class takes no parameters

Check this out to see if reproducible.



 Comments   
Comment by Thomas Hofmann [ 01/Dec/11 ]

I tried this again and version 2.5.2 installs fine and is not causing the enum problem I have seen before. I don't think it was a problem with the groovy eclipse plug-in. I have some idea what was causing it and will dig into that now. I think it is save to at least change the priority of this issue.

Comment by Thomas Hofmann [ 05/Dec/11 ]

I recreated this issue. The problem only occurred because I was importing an eclipse preferences file with classpath variables I wanted to set in the workspace like this:

/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.VEDOC_CLIENT=C\:/vedoc/clientcontainer/launcher/VEDOC
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.VEDOC_SERVER=C\:/vedoc/server
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.GROOVY_HOME=C\:/groovy

This somehow seams to mess up the JDT internal settings leading to the problem.

I solved this by including all JDT sepcific settings in the preference file I am importing into the workspace like this:

/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.VEDOC_CLIENT=C\:/vedoc/clientcontainer/launcher/VEDOC
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.VEDOC_SERVER=C\:/vedoc/server
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.GROOVY_HOME=C\:/groovy
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.argumentPrefixes=
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.argumentSuffixes=
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.fieldPrefixes=f
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.fieldSuffixes=
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.localPrefixes=
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.localSuffixes=
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.staticFieldPrefixes=
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.staticFieldSuffixes=
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.codeComplete.visibilityCheck=enabled
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.6
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.compliance=1.6
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.deprecationWhenOverridingDeprecatedMethod=enabled
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.fieldHiding=warning
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.localVariableHiding=warning
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.missingSerialVersion=ignore
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.redundantNullCheck=warning
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.unnecessaryTypeCheck=warning
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.source=1.6
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.taskCaseSensitive=enabled
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.taskPriorities=NORMAL,HIGH,NORMAL
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.taskTags=TODO,FIXME,XXX
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.align_type_members_on_columns=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_arguments_in_allocation_expression=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_arguments_in_enum_constant=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_arguments_in_explicit_constructor_call=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_arguments_in_method_invocation=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_arguments_in_qualified_allocation_expression=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_assignment=0
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_binary_expression=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_compact_if=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_conditional_expression=80
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_enum_constants=0
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_expressions_in_array_initializer=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_multiple_fields=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_parameters_in_constructor_declaration=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_parameters_in_method_declaration=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_selector_in_method_invocation=80
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_superclass_in_type_declaration=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_superinterfaces_in_enum_declaration=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_superinterfaces_in_type_declaration=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_throws_clause_in_constructor_declaration=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.alignment_for_throws_clause_in_method_declaration=16
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_after_imports=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_after_package=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_before_field=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_before_first_class_body_declaration=0
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_before_imports=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_before_member_type=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_before_method=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_before_new_chunk=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_before_package=0
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_between_import_groups=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.blank_lines_between_type_declarations=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_annotation_type_declaration=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_anonymous_type_declaration=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_array_initializer=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_block=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_block_in_case=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_constructor_declaration=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_enum_constant=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_enum_declaration=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_method_declaration=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_switch=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.brace_position_for_type_declaration=end_of_line
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.clear_blank_lines_in_block_comment=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.clear_blank_lines_in_javadoc_comment=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.format_block_comments=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.format_header=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.format_html=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.format_javadoc_comments=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.format_line_comments=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.format_source_code=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.indent_parameter_description=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.indent_root_tags=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.insert_new_line_before_root_tags=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.insert_new_line_for_parameter=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.comment.line_length=120
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.compact_else_if=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.continuation_indentation=2
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.continuation_indentation_for_array_initializer=2
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.format_guardian_clause_on_one_line=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_body_declarations_compare_to_annotation_declaration_header=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_body_declarations_compare_to_enum_constant_header=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_body_declarations_compare_to_enum_declaration_header=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_body_declarations_compare_to_type_header=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_breaks_compare_to_cases=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_empty_lines=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_statements_compare_to_block=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_statements_compare_to_body=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_cases=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.indentation.size=4
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_local_variable=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_member=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_parameter=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_after_opening_brace_in_array_initializer=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_at_end_of_file_if_missing=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_before_catch_in_try_statement=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_before_closing_brace_in_array_initializer=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_before_else_in_if_statement=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_before_finally_in_try_statement=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_before_while_in_do_statement=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_in_empty_annotation_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_in_empty_anonymous_type_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_in_empty_block=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_in_empty_enum_constant=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_in_empty_enum_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_in_empty_method_body=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_new_line_in_empty_type_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_and_in_type_parameter=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_assignment_operator=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_at_in_annotation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_at_in_annotation_type_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_binary_operator=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_closing_angle_bracket_in_type_arguments=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_closing_angle_bracket_in_type_parameters=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_closing_brace_in_block=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_closing_paren_in_cast=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_colon_in_assert=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_colon_in_case=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_colon_in_conditional=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_colon_in_for=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_colon_in_labeled_statement=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_allocation_expression=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_annotation=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_array_initializer=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_constructor_declaration_parameters=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_constructor_declaration_throws=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_enum_constant_arguments=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_enum_declarations=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_explicitconstructorcall_arguments=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_for_increments=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_for_inits=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_method_declaration_parameters=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_method_declaration_throws=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_method_invocation_arguments=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_multiple_field_declarations=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_multiple_local_declarations=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_parameterized_type_reference=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_superinterfaces=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_type_arguments=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_comma_in_type_parameters=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_ellipsis=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_angle_bracket_in_parameterized_type_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_angle_bracket_in_type_arguments=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_angle_bracket_in_type_parameters=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_brace_in_array_initializer=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_bracket_in_array_allocation_expression=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_bracket_in_array_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_annotation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_cast=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_catch=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_constructor_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_enum_constant=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_for=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_if=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_method_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_method_invocation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_parenthesized_expression=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_switch=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_synchronized=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_opening_paren_in_while=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_postfix_operator=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_prefix_operator=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_question_in_conditional=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_question_in_wildcard=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_semicolon_in_for=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_after_unary_operator=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_and_in_type_parameter=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_assignment_operator=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_at_in_annotation_type_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_binary_operator=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_angle_bracket_in_parameterized_type_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_angle_bracket_in_type_arguments=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_angle_bracket_in_type_parameters=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_brace_in_array_initializer=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_bracket_in_array_allocation_expression=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_bracket_in_array_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_annotation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_cast=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_catch=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_constructor_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_enum_constant=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_for=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_if=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_method_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_method_invocation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_parenthesized_expression=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_switch=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_synchronized=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_closing_paren_in_while=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_colon_in_assert=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_colon_in_case=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_colon_in_conditional=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_colon_in_default=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_colon_in_for=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_colon_in_labeled_statement=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_allocation_expression=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_annotation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_array_initializer=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_constructor_declaration_parameters=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_constructor_declaration_throws=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_enum_constant_arguments=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_enum_declarations=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_explicitconstructorcall_arguments=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_for_increments=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_for_inits=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_method_declaration_parameters=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_method_declaration_throws=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_method_invocation_arguments=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_multiple_field_declarations=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_multiple_local_declarations=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_parameterized_type_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_superinterfaces=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_type_arguments=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_comma_in_type_parameters=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_ellipsis=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_angle_bracket_in_parameterized_type_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_angle_bracket_in_type_arguments=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_angle_bracket_in_type_parameters=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_annotation_type_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_anonymous_type_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_array_initializer=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_block=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_constructor_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_enum_constant=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_enum_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_method_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_switch=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_brace_in_type_declaration=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_bracket_in_array_allocation_expression=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_bracket_in_array_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_bracket_in_array_type_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_annotation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_annotation_type_member_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_catch=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_constructor_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_enum_constant=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_for=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_if=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_method_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_method_invocation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_parenthesized_expression=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_switch=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_synchronized=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_opening_paren_in_while=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_parenthesized_expression_in_return=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_parenthesized_expression_in_throw=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_postfix_operator=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_prefix_operator=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_question_in_conditional=insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_question_in_wildcard=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_semicolon=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_semicolon_in_for=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_before_unary_operator=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_between_brackets_in_array_type_reference=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_between_empty_braces_in_array_initializer=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_between_empty_brackets_in_array_allocation_expression=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_between_empty_parens_in_annotation_type_member_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_between_empty_parens_in_constructor_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_between_empty_parens_in_enum_constant=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_between_empty_parens_in_method_declaration=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.insert_space_between_empty_parens_in_method_invocation=do not insert
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.keep_empty_array_initializer_on_one_line=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.lineSplit=400
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.never_indent_block_comments_on_first_column=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.never_indent_line_comments_on_first_column=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.number_of_blank_lines_at_beginning_of_method_body=0
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.number_of_empty_lines_to_preserve=1
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.put_empty_statement_on_new_line=true
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.tabulation.char=tab
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.tabulation.size=4
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.use_tabs_only_for_leading_indentations=false
/instance/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.wrap_before_binary_operator=true

I don't think this issue can be resolved as invalid.

Comment by Andrew Eisenberg [ 05/Dec/11 ]

Can you be very clear about the steps you took to reproduce? Then I'll try it out over here.

I wonder if the problem is that in your new workspace you did not set the default source/target/compliance levels. If you don't, then there is a default-default of Java 1.4. This would explain why the class Enum does not have any type parameters (but it does not explain why enums are not flagged as errors. Anyway, this is just a possibility.

Comment by Andrew Eisenberg [ 26/Jan/12 ]

I tried to reproduce this naively, but not able to. I am resolving this bug, but if you can describe a way to reproduce this, I will look at it again.





[GRECLIPSE-1262] Auto-add curly brace after closure definition with an argument Created: 24/Nov/11  Updated: 18/Jan/12  Resolved: 24/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes GRECLIPSE-1232 Better content assist for methods wit... Resolved
Number of attachments : 0

 Description   

When there is a single curly brace at the end of a line and enter is pressed, the brace is automatically closed at the correct indent level. Eg:

foo {|

becomes:

foo {
    |
}

However, if the closure has arguments, then the brace is not autoclosed. Eg-

foo { String x ->|

becomes:

foo { String x ->
|

This would be good to fix as we are changing the way that content assist inserts closures.



 Comments   
Comment by Andrew Eisenberg [ 24/Nov/11 ]

Now fixed. Kris did the work and I added a couple of regression tests.





[GRECLIPSE-1261] Defined DSLD does not work in static method Created: 23/Nov/11  Updated: 18/Jan/12  Resolved: 18/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Matthias Hryniszak Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.8.0


Issue Links:
dependent
is depended upon by GRECLIPSE-1224 Incorrect inferencing of non-static r... Resolved
Testcase included: yes
Number of attachments : 0

 Description   

With the following definition in dsld/test.dsld

contribute(currentType('java.lang.String'))

{ method name: "testme", type: boolean }

content assistant and underlining only works in non-static methods. For example

class Program {
static main(String[] args)

{ 1.testme() }

// testme unknown
void test()

{ "".testme() }

// works
}

This issue causes diving into the whole idea of DSLD pretty hard since most of the entry-level testing will be done inside of static main methods...



 Comments   
Comment by Andrew Eisenberg [ 24/Nov/11 ]

Looks like a bug in that we are interpreting static scope incorrectly.

Comment by Andrew Eisenberg [ 24/Nov/11 ]

Yes. This was what I expected. The DSLD type lookup is now correctly determining what is a static reference and what is not. I committed the fix and the next snapshot build will contain it. The build will be available in about an hour (assuming the changes haven't broken anything else). I suggest that you upgrade.

Comment by Matthias Hryniszak [ 25/Nov/11 ]

I must be blind or something... Is there an update site I can use to upgrade the plugin to the snapshot version you mentioned?

Comment by Andrew Eisenberg [ 25/Nov/11 ]

Here's the link:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

Comment by Matthias Hryniszak [ 27/Nov/11 ]

I can confirm it works now. Thanks!

Comment by Andrew Eisenberg [ 27/Nov/11 ]

Thanks for verifying.





[GRECLIPSE-1260] Eclipse Groovy Plugin Hanging Eclipse on a regular basis Created: 23/Nov/11  Updated: 05/Jan/12  Resolved: 05/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Critical
Reporter: Kirk Rasmussen Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64-bit, JRockit 1.6.0_26-b03, Eclipse Version: 3.7.1 (Build id: M20110909-1335)


Number of attachments : 0

 Description   

I am currently experiencing a near show stopper issue with the Eclipse Groovy plugin with a large Groovy codebase (2K+ classes broken into multiple projects). The general symptom is after I do something that engages auto-complete or viewing javadoc (e.g. hit F2 when hovering on class) Eclipse "freezes". It acts as if the UI thread has stopped processing events and I get the typical Windows "no response" in the title bar with an opaque white screen. At this point Eclipse is dead in the water and I have to kill it.

My Eclipse JVM is configured to use JRockit ((1.6.0_26-b03)) and I was able to capture some interesting information with Mission Control. There are two threads that are endless looping on the following (each thread consuming 25% cpu):

java.util.HashMap$HashIterator.hasNext line: 972
java.util.HashMap.buildCache line: 589
java.util.HashMap.resize line: 576
java.util.HashMap.addEntry line: 939
java.util.HashMap.put line: 477
org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.createJDTClassNode line: 361

Eclipse is still technically running but its unusable once it gets into this state — it's not responsive to keyboard or mouse input. I've paired my environment down to a single project and it still seems to happen although less frequently. Today Eclipse "crashed" on me 11 times. I've observed this same behavior with the groovy 2.5.2 plugin and the 2.6.0 daily builds. The stack trace above is from 2.5.2. This is fairly easy for me to reproduce and I always see the exact same threads in the same endless looping behavior.

I'm running on the JRocket Windows 64-bit JVM with Eclipse (Version: 3.7.1 Build id: M20110909-1335). We are using a Pulse account to manage our shared Eclipse configuration in the office. For some reason I tend to crash more than other people in my software group albeit we don't have the same hardware exactly. I'm running on an Intel Core Extreme CPU Q9300 @ 2.53GHz with 8GB of RAM.

Thanks for your help! Let me know if there is any other information that would help track this problem down.



 Comments   
Comment by Andy Clement [ 23/Nov/11 ]

i'll take a look

Comment by Andy Clement [ 23/Nov/11 ]

I made the relevant HashMap synchronized, let's see if that helps. A dev build later today should contain the change, I'll let you know when.

Comment by Kirk Rasmussen [ 23/Nov/11 ]

Wow that was fast. I'll give that a try later. Thanks!

Comment by Andy Clement [ 23/Nov/11 ]

dev build is available, please give it a try.

Comment by Andrew Eisenberg [ 01/Dec/11 ]

Kirk, any update on this problem?

Comment by Kirk Rasmussen [ 01/Dec/11 ]

Hey guys sorry I didn't update sooner. I just updated today with the 2.6.0.xx-20111130-1500-e37 build it seems to have helped. I'll continue to put it though its paces and update again later this week – fingers crossed!

Thanks for your help. Much appreciated.

Comment by Kirk Rasmussen [ 06/Dec/11 ]

It seems to have helped but I saw slow down (although NOT a "crash") but only once. CPU was continuous 25% for a few minutes before I restarted. I'm not sure if I can attribute this to groovy plugin or not unfortunately because I wasn't able to grab a stack trace – i forgot

I'll keep plugging away but it is definitely more stable than before!

Comment by Kirk Rasmussen [ 06/Dec/11 ]

When I said "crash" above I meant that Eclipse was still usable (unlike before) but with poor performance.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Hi Kirk, without anything more concrete there is not much that we can do. If you can catch a thread dump, we will have another look.

Comment by Kirk Rasmussen [ 05/Jan/12 ]

Hi Andrew I'm pretty confident that this is fixed now. I have not experienced any deadlocks since so I suspect the one issue I reported on 06/Dec may have been unrelated.

Comment by Andrew Eisenberg [ 05/Jan/12 ]

Thanks for getting back to us. Assuming fixed, but don't hesitate to open a new bug or comment on this one if you continue to see problems.





[GRECLIPSE-1259] Make parameter guessing content assist guess better parameters. Created: 22/Nov/11  Updated: 18/Jan/12  Resolved: 24/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes GRECLIPSE-1232 Better content assist for methods wit... Resolved
Number of attachments : 0

 Description   

Parameter guessing could be implemented better. Sometimes it does not propose the interesting possibilities and other times, it proposes things that are not interesting. We can do better here.



 Comments   
Comment by Andrew Eisenberg [ 23/Nov/11 ]

I should be more specific here as to what the current problems are:

  • methods not proposed
  • sometimes fields or properties from incorrect types are proposed
  • a getter or isser variant of a field is proposed, but is proposed as a local variable, not as a method.
Comment by Andrew Eisenberg [ 23/Nov/11 ]

After some exploration, I have been able to do the following:

  • propose getter and isser methods as method proposals
  • remove the getter/isser variant of a property from the list of proposals

I think it would be more groovy-like to avoid proposing any getters or issers, and instead propose the property form of these variables. I will work on that next.

Comment by Andrew Eisenberg [ 23/Nov/11 ]

Also, for String types, we should always propose an empty string.

Comment by Andrew Eisenberg [ 23/Nov/11 ]

And for closure types, always propose '{ }'.

Comment by Andrew Eisenberg [ 23/Nov/11 ]

All of the work specified here is complete, but I still need to create tests.

However, there is something that I am not too happy about. When selecting the completion for an empty string:

""

I was hoping that the caret would be placed in the middle of the quotes:

"|"

But, instead the selection covers it. The same with { }.

Comment by Andrew Eisenberg [ 24/Nov/11 ]

Current status:

  • No longer proposing null for closures and strings. Instead, proposing an opening curly brace and an empty string respectively.
  • Thanks to the fix for GRECLIPSE-1261, when selecting a closure proposal, it will automatically close the closure declaration when pressing enter.

Unfortunately, the parameter guessing code is split across a few locations with a bit of duplication. I need to clean this up a bit and write a few tests before I commit.

Comment by Andrew Eisenberg [ 24/Nov/11 ]

Committed fix with regression tests.





[GRECLIPSE-1258] Convert to single line string quick assist Created: 18/Nov/11  Updated: 16/Jan/12  Resolved: 18/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: quick-assist
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This is the analog of GRECLIPSE-1252. Now committed with regression tests.






[GRECLIPSE-1257] Groovy-Eclipse-compiler does not recognize src/main/groovy and src/test/groovy as source folders if there are no files in src/main/java Created: 18/Nov/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Minor
Reporter: Oliver Blaha Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Groovy-Eclipse-compiler does not recognize src/main/groovy and src/test/groovy as source folders in our project.
As sonn there is e.g. an empty Dummy.java in src/main/java, groovy folders are recognized correctly. Creating a dummy file is an easy workaround, but should not be necessary.



 Comments   
Comment by Andrew Eisenberg [ 18/Nov/11 ]

Duplicate of GRECLIPSE-1221





[GRECLIPSE-1255] More fun with default parameters Created: 15/Nov/11  Updated: 18/Jan/12  Resolved: 17/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Search
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File GECLIPSE_1255_more_fun.patch    
Issue Links:
Related
is related to GRECLIPSE-1256 Use a classfile attribute in the clas... Open
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Seems like the work in GRECLIPSE-1233 is not complete. Mark occurrences is not correct when there are default parameter references coming from other files. Eg-

class C {
    def xxx(a, b = 2) {}
} 

and in another file:

def obj
new C().xxx()
new C().xxx(obj)
new C().xxx(obj, obj)
new C().xxx(obj, obj, obj) 

Select the first, third or fourth method reference and the first, third, and fourth reference highlights. Select the second, and only the second highlights.

The correct behavior is that selecting any method reference should select all other references. This is the behavior that you see when all are inside the same file.



 Comments   
Comment by Kris De Volder [ 16/Nov/11 ]

This is a patch I received from one of last nights hackathon participants.

It solves the highlighting issue by ignoring parameters in the case where the references is a 'JDTMethodNode'.

Comment by Andrew Eisenberg [ 17/Nov/11 ]

Thanks for the patch. Reasonable fix even if behavior is not completely preserved. See GRECLIPSE-1256 for a better long term solution to this bug.





[GRECLIPSE-1252] Convert to multi-line string quick assist Created: 15/Nov/11  Updated: 16/Jan/12  Resolved: 18/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: New Feature Priority: Minor
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: help-requested, quick-assist
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File org.codehaus.groovy.eclipse.quickfix.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

This quick-assist will convert from a single-line string to a multiline string.

Eg-

'hello'

becomes

'''hello'''

and

"hello"

becomes

"""hello"""


 Comments   
Comment by Nick Sawadsky [ 16/Nov/11 ]

Hi Andrew,

Here is the patch I created! Seems to work, let me know what you think. Thanks again for all your help.

Nick

Comment by Andrew Eisenberg [ 17/Nov/11 ]

Thanks for the patch. I'm still going through it. I had to make one change. You were using Arrays.copyOfRange. However, Groovy-Eclipse must support the Java 5 JDK, so I changed it to System.arrayCopy.

I'm also considering removing escapes, so things like \n will be converted into actual newlines. Are you interested in doing this yourself?

Comment by Andrew Eisenberg [ 18/Nov/11 ]

Committed the patch. Added support for escaping characters and added regression tests.





[GRECLIPSE-1250] Remove semi-colons quick-assist Created: 15/Nov/11  Updated: 16/Jan/12  Resolved: 05/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: New Feature Priority: Minor
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: help-requested, quick-assist
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File GRECLIPSE-1250.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Invoking this quick assist will remove all semi-colons at the end of statements from the file.



 Comments   
Comment by Renato Garcia [ 02/Dec/11 ]

Patch with the implementation based on ConvertToClosureCompletionProposal

Comment by Andrew Eisenberg [ 02/Dec/11 ]

Thanks for the patch! I'll take a look at it this weekend or next week.

Comment by Andrew Eisenberg [ 05/Dec/11 ]

Patch looks good. Just needs a bit of reformatting to adhere to Groovy-Eclipse's style guidelines. Thanks for your contribution.





[GRECLIPSE-1248] Support for Groovy 1.8.4 Created: 10/Nov/11  Updated: 18/Jan/12  Resolved: 15/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Improvement Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andy Clement [ 15/Nov/11 ]

fixed





[GRECLIPSE-1247] [x:1].getAt( "x" ) does not infer type of map value Created: 09/Nov/11  Updated: 26/Jan/12  Resolved: 26/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GRECLIPSE-1299 Return types of DGMs that have a type... Open
Number of attachments : 0

 Description   

The following does not infer the type of the value at the key x (Integer:

[x:1].getAt( "x" ).intValue() 


 Comments   
Comment by Andrew Eisenberg [ 26/Jan/12 ]

Duplicate of GRECLIPSE-1299. This has to do with type parameters on methods, which we currently ignore.





[GRECLIPSE-1245] Open declaration on static method in parent class from child method selects child class name Created: 09/Nov/11  Updated: 09/Nov/11  Resolved: 09/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In Parent.groovy:

class Parent {
    static p() {}
}

In Child.groovy:

class Child extends Parent {
    def c() {
        p()
    }
}

Control-clicking (or pressing F3) on p in Child.groovy will select Child and not navigate to Parent.p



 Comments   
Comment by Andrew Eisenberg [ 09/Nov/11 ]

Duplicate of GRECLIPSE-1244

Comment by Andrew Eisenberg [ 09/Nov/11 ]

Fix resolution.





[GRECLIPSE-1244] Open declaration on static method in parent class from child method selects child class name Created: 09/Nov/11  Updated: 18/Jan/12  Resolved: 21/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Critical
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In Parent.groovy:

class Parent {
    static p() {}
}

In Child.groovy:

class Child extends Parent {
    def c() {
        p()
    }
}

Control-clicking (or pressing F3) on p in Child.groovy will select Child and not navigate to Parent.p



 Comments   
Comment by Andrew Eisenberg [ 20/Nov/11 ]

Thanks for this. It is reproducible and is likely a regression (although I apparently don't have any tests for this). I'm bumping up the priority.

It looks like it is a bug in the code select logic since searching and mark occurrences work as expected.

Comment by Andrew Eisenberg [ 20/Nov/11 ]

Hmmm...a quick look is showing that the AST is incorrect at the location of the method call. The AST node of the p() is of type StaticMethodCall. An instance of this type has a method getOwner, which should point to the type that declares the static method. However, in this case, the getOwner is of type Child (even though it should be Parent).

I need to look deeper into the compiler this to see why this is happening. I definitely could work around this problem, but I'd prefer to find the root cause.

Comment by Andrew Eisenberg [ 21/Nov/11 ]

My assumption about what the correct AST should look like was wrong. And so the code that you pasted above never worked. I created a fix for this. Now, type inferencing does not choose the declaring type based on the owner, rather it actually searches for the real definition of the static method. This appears to work and I have a few regression tests. Will commit shortly.

Comment by Andrew Eisenberg [ 21/Nov/11 ]

Committed fix.





[GRECLIPSE-1243] Ability to import static non-existent members Created: 09/Nov/11  Updated: 01/Feb/12  Resolved: 31/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Editor
Affects Version/s: None
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following is currently possible in the editor, without a compilation error or underlining:

import static java.lang.Math.FOO


 Comments   
Comment by Andrew Eisenberg [ 09/Nov/11 ]

This is something that the compiler should be checking, but isn't. Compiling this on the command line does not give any errors. There might be something that we could do to augment the compilation (as we do with unused imports), but it may be outside the scope of our compiler integration.

Comment by Bob Tiernay [ 04/Dec/11 ]

I'm not sure if this should be an error, but it should at least be underlined in the editor. Is that possible?

Comment by Bob Tiernay [ 27/Dec/11 ]

Should I file a Groovy bug?

Comment by Andrew Eisenberg [ 27/Dec/11 ]

Yes, this does look like a compiler error. The compiler should warn about an unknown import, but this script completes for me with no errors:

import static java.lang.Math.FOO

println "done."
Comment by Bob Tiernay [ 27/Dec/11 ]

Okay, created https://jira.codehaus.org/browse/GROOVY-5218

Comment by Bob Tiernay [ 16/Jan/12 ]

The more I think about this issue, the more I think that what groovyc is doing is actually correct. This is mainly due to the ability to perform dynamic metaprogramming on statics. For example, the following is valid groovy:

Math.metaClass.static.getFOO = {-> 1 }
java.lang.Math.FOO
Comment by Bob Tiernay [ 16/Jan/12 ]

If the above seems logical, then perhaps the editor should underline the unknown reference. This would make spotting these unknown references a lot easier when enums, constants, static methods etc. are renamed.

Comment by Bob Tiernay [ 24/Jan/12 ]

Looks like https://jira.codehaus.org/browse/GROOVY-5218 is valid groovy code. Thoughts?

Comment by Andrew Eisenberg [ 24/Jan/12 ]

My first inclination is to say, "just don't do it". But, that's probably not satisfying.

A complete solution would be to underline statically non-existant imports, and then let users augment this functionality through DSLDs. I'd even say that it is reasonable to do the underlining now, and just not have any support for augmentation via DSLDs for now, since this seems like a rare occurrence.

Comment by Bob Tiernay [ 24/Jan/12 ]

That makes sense to me

Comment by Bob Tiernay [ 26/Jan/12 ]

Okay, just an update from the Groovy JIRA: "Note: Groovy does not check beyond your import class if what you statically import exists. If you import a nonexisting method, field or property Groovy will not fail at compile time, but later when executing the compiled code."

Comment by Andrew Eisenberg [ 31/Jan/12 ]

Made some big changes to how static imports are handled. I committed a fix for this.

As I mentioned, the correct thing to do is underline unknown references and let the DSLD determine if they should otherwise be valid.

Comment by Bob Tiernay [ 01/Feb/12 ]

Awesome work Andrew. A great improvement to GRECLIPSE!





[GRECLIPSE-1240] Better content assist for basic command expression based DSLs Created: 08/Nov/11  Updated: 05/Oct/12  Resolved: 05/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, DSL Support
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Improvement Priority: Major
Reporter: Zach Shepherd Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, if an implementer of a command expression based DSL (http://docs.codehaus.org/display/GroovyJSR/GEP+3+-+Command+Expression+based+DSL) attempts to provide content assist for his or her users by implementing a DSLD, the produced code may not match his or her expectations.

For example, an implementer of the move keyword described in the above document might wish to have the following behavior for users.

user keystrokes
mo<ctrl+space><enter>
content assist (with the vertical pipe indicating cursor position)
move |

However, if a user attempts to implement this today with the below dsld, the behavior is as follows.

example dsld
    method name : 'move',
       type: void,
       declaringType: 'com.example.MoveSyntax',
       params : [direction : String],
       doc : 'move in the specified direction' 
current behavior (with the vertical pipe indicating cursor position)
move(|null|)


 Comments   
Comment by Andrew Eisenberg [ 08/Nov/11 ]

In this situation, would you be fine with content assist completing with no parens? Eg:

move |null|

The null appears because Groovy-Eclipse is trying to be smart and looking through local context for things that have a String type. In this case, there is nothing, so it proposes null. In this case, things would be much different:

String a = ""
String b = ""
move |b|

The text placed in would be b, but there would be a drop down allowing you to choose a or null instead.

There used to be a mode where content would try to add parameters without parens, but this never worked too well since it's hard to distinguish when parens are acceptable and when they are not. It is even harder when command expressions are involved. This information is not retained in the AST and so we would need to revert to text scanning to look for parens. It is something that should be possible.

Comment by Zach Shepherd [ 09/Nov/11 ]

In this situation, would you be fine with content assist completing with no parens?

An empty string seems like a more sane default than null, but simply completing without parens would be an improvement.

There used to be a mode where content would try to add parameters without parens, but this never worked too well since it's hard to distinguish when parens are acceptable and when they are not.

Perhaps this could be something that would be specified in the DSLD?

modified dsld
method name : 'move',
       type: void,
       declaringType: 'com.example.MoveSyntax',
       params : [direction : String],
       doc : 'move in the specified direction',
       parens : false

This way no guess work/deduction would be necessary.

Comment by Andrew Eisenberg [ 05/Oct/12 ]

This is now available in the latest snapshots.

I have chosen to use noParenss rather than parens. Despite the double negative, this is a better choice since the default for this value must be false.

So, the following method contribution:

method name: 'foo', params: [a:String,b:int], noParens:true

would apply like this:

foo a, b

Remove the noParens or set it to false and the proposal is applied like this:

foo(a, b)

Where a and b are filled in with sensible defaults and have sub-proposals as with regular method proposals.

This is the basic building of command expressions.





[GRECLIPSE-1239] GroovyEditor Maxes out CPU Usage Created: 07/Nov/11  Updated: 21/Dec/11  Resolved: 21/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Robert Winch Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Spring Tool Suite 2.8.0.RELEASE, Groovy Eclipse 2.6.0.xx-20111104-1100-e37 using Groovy Compiler 1.7.10.xx-20111104-1100-e37


Attachments: Zip Archive groovyeditormaxcpu.snapshot.zip     Text File groovyeditormaxcpu-threads.txt     Text File hotspots.txt    
Number of attachments : 3

 Description   

I edited a Groovy class and then the main thread became blocked indefinitely waiting for a lock that is held by Worker-93 thread (a GroovyEditor background thread). It appears that Worker-93 thread is in an infinite loop because the CPU is maxed out and that thread never terminates despite the fact it is not blocked. Below is a summary of what I think are the relevant threads. I have attached a full thread dump and a YourKit snapshot to the issue.

"main" prio=10 tid=0x0826a000 nid=0x827 waiting for monitor entry [0xbfa9a000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:152)
	- waiting to lock <0x4ff38820> (a java.lang.Object)
	at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1072)

"Worker-93" prio=10 tid=0xa0de2c00 nid=0x24a4 runnable [0xa1dfd000]
   java.lang.Thread.State: RUNNABLE
	at org.eclipse.jdt.internal.compiler.util.SimpleLookupTable.get(SimpleLookupTable.java:72)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createParameterizedType(LookupEnvironment.java:940)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1346)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:555)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:635)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:370)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:678)
	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:308)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:119)
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:127)
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:861)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:105)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:1135)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.methods(BinaryTypeBinding.java:1107)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initializeMembers(JDTClassNode.java:254)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:231)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:155)
	- locked <0x4ff38820> (a java.lang.Object)
	at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1072)


 Comments   
Comment by Andrew Eisenberg [ 07/Nov/11 ]

Any chance that you can share with me the project (or at least the class declaration) where this occurs? Feel free to contact me directly if you don't want the project posted publicly.

aeisenberg at vmware dot com.

Comment by Robert Winch [ 07/Nov/11 ]

I just sent you an email with the two files I was working on.

Comment by Robert Winch [ 07/Nov/11 ]

I should have probably emphasized that this does not happen frequently, so you can probably bump the priority down quite a bit.

Comment by Andrew Eisenberg [ 07/Nov/11 ]

Got the email. I'll have a look.

Comment by Andrew Eisenberg [ 11/Nov/11 ]

Looking at the stack dump that is attached to this bug, I can see that this is not a deadlock state and I would like to see what the loop is. Unfortunately, your yourkit snapshot is in v10 and my license key has expired for that version. I'll try to get another license key next week.

Comment by Robert Winch [ 12/Nov/11 ]

I'm not sure if this helps, but I attached an export of the hot spots. If there is anything else I can do to assist. Please do not hesitate to let me know.

Comment by Andrew Eisenberg [ 29/Nov/11 ]

Finally got my hands on a yourkit v10 license. I'll have a look at your snapshot.

Comment by Andrew Eisenberg [ 20/Dec/11 ]

Are you still having trouble here? I looked at your snapshot and I couldn't find anything obvious.

Comment by Robert Winch [ 21/Dec/11 ]

Thanks for following up. I have not seen this issue in a while.

Comment by Andrew Eisenberg [ 21/Dec/11 ]

Here's what I would recommend. If you see this problem again, try to remember what files you were working on. It would also be great if you could send over the project that you were working on (I know that this is often not possible, but you can send it privately if it contains proprietary information).

I will resolve this as cannot reproduce, but feel free to comment again if you see it. And I will reopen the issue.





[GRECLIPSE-1238] parameterized type navigation not quite right Created: 07/Nov/11  Updated: 06/Dec/11  Resolved: 06/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Minor
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When I have a parameterized type like this:

class Bar implements SomeInterface<SomeClass> {

when I hover over 'SomeClass' and navigate to the declaration it takes me to SomeInterface, not SomeClass.



 Comments   
Comment by Andrew Eisenberg [ 06/Dec/11 ]

Fix committed with regression tests.





[GRECLIPSE-1237] compiler freezing on projects with classpatherrors Created: 07/Nov/11  Updated: 04/Feb/13  Resolved: 04/Feb/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Critical
Reporter: Peter Rader Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: eclipse
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux, sts-eclipse


Attachments: Text File debug.txt    
Number of attachments : 1

 Description   

After 36 classpath problems the build-progress freezes and the build can't be aborted.



 Comments   
Comment by Andy Clement [ 07/Nov/11 ]

If it is hanging, can you try to collect a stack trace to show what it is up to? use 'jps' to get the process id, then 'jstack' to get a stack for that process. thanks.

Comment by Peter Rader [ 08/Nov/11 ]

output of jstack

Comment by Andrew Eisenberg [ 05/Oct/12 ]

My guess is that things are not hanging here, but just progressing really, really slowly. In older versions of the groovy compiler, unresolved classes would not be cached. So, every time an unresolvable class was found, even if the compiler had just tried to resolve it, another resolve attempt would occur. Resolve attempts are very, very slow, especially when they fail.

With later versions of 1.8.6, and 2.0, we are now caching unresolved classes and this situation should be much slower.

Is this still a problem for you? If so, there may be something else going on.

Comment by Andrew Eisenberg [ 04/Feb/13 ]

No response from original reporter. Resolving because cannot reproduce. Problem could also come about from limited memory on the heap causing thrashing.





[GRECLIPSE-1236] code completion StringIndexOutOfBoundsException exception Created: 04/Nov/11  Updated: 18/Jan/12  Resolved: 04/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

this one is from an older build (not todays 4th Nov), just noticed it in my error log. Not sure what causes it:

java.lang.StringIndexOutOfBoundsException: String index out of range: 2
	at java.lang.String.charAt(String.java:686)
	at org.codehaus.groovy.eclipse.codeassist.creators.AbstractProposalCreator.looselyMatchesGetterName(AbstractProposalCreator.java:110)
	at org.codehaus.groovy.eclipse.codeassist.creators.MethodProposalCreator.findAllProposals(MethodProposalCreator.java:71)
	at org.codehaus.groovy.eclipse.codeassist.processors.StatementAndExpressionCompletionProcessor.generateProposals(StatementAndExpressionCompletionProcessor.java:364)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.internalComputeCompletionProposals(GroovyCompletionProposalComputer.java:156)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.computeCompletionProposals(GroovyCompletionProposalComputer.java:108)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:318)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:267)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:283)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:243)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1830)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:488)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482)
	at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1656)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:183)
	at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185)
	at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
	at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1069)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4127)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1457)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1480)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1465)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1494)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1490)
	at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:463)
	at org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1051)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5563)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
	at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5473)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220)
	at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2092)
	at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2252)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5535)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:4989)
	at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5138)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3610)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)



 Comments   
Comment by Andrew Eisenberg [ 04/Nov/11 ]

Another silly problem. Must have been around for a while. If there is a method or field named is, and you are doing content assist with a prefix of is the exception is thrown. Was using a <= instead of a <.





[GRECLIPSE-1235] code completion exception Created: 04/Nov/11  Updated: 18/Jan/12  Resolved: 04/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

new String(<Ctrl+Space>)

produces


java.lang.IllegalArgumentException
	at org.eclipse.jdt.internal.codeassist.InternalCompletionProposal.<init>(InternalCompletionProposal.java:443)
	at org.codehaus.groovy.eclipse.codeassist.processors.GroovyCompletionProposal.<init>(GroovyCompletionProposal.java:65)
	at org.codehaus.groovy.eclipse.codeassist.processors.GroovyProposalTypeSearchRequestor.createProposal(GroovyProposalTypeSearchRequestor.java:935)
	at org.codehaus.groovy.eclipse.codeassist.processors.GroovyProposalTypeSearchRequestor.proposeConstructor(GroovyProposalTypeSearchRequestor.java:773)
	at org.codehaus.groovy.eclipse.codeassist.processors.GroovyProposalTypeSearchRequestor.processAcceptedConstructors(GroovyProposalTypeSearchRequestor.java:701)
	at org.codehaus.groovy.eclipse.codeassist.processors.ConstructorCompletionProcessor.generateProposals(ConstructorCompletionProcessor.java:64)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.internalComputeCompletionProposals(GroovyCompletionProposalComputer.java:156)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.computeCompletionProposals(GroovyCompletionProposalComputer.java:108)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:318)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:267)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:283)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:243)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1830)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:488)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482)
	at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1656)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:183)
	at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185)
	at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
	at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1069)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4127)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1457)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1480)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1465)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1494)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1490)
	at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:463)
	at org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1051)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5563)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
	at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5473)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220)
	at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2092)
	at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2252)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5535)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:4989)
	at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5138)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3610)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)


 Comments   
Comment by Andrew Eisenberg [ 04/Nov/11 ]

Fixed. I was basing source location off of a fully qualified name of the type. Most of the time, this does not have any effect, except when the content assist invocation location is shorter than the length of the fully qualified name.

Now, I am being more careful to appropriately pick the qualified or unqualified name to base content assist on.





[GRECLIPSE-1234] Occasional stackoverflow error when editing .groovy files Created: 04/Nov/11  Updated: 15/Mar/12  Resolved: 15/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Parser
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.7.0.Release

Type: Bug Priority: Critical
Reporter: Danilo Tommasina Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When editing .groovy files we sometimes get the following error:

Exception in thread "org.eclipse.jdt.internal.ui.text.JavaReconciler" java.lang.StackOverflowError
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1240)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1251)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1251)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1251)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1251)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1251)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1251)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1251)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
        at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1251)
        at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
(...)

After that eclipse will ask to restart the workbench, if you hit 'No' the problem will immediately occur again unless you are fast enough and manage to close the editor tab containing the groovy file.



 Comments   
Comment by Andrew Eisenberg [ 04/Nov/11 ]

Can you paste the file here that is giving you the trouble? It looks like the problem is with recursively defined generic type parameters (such as for enums, where the declaration is Enum<? extends Enum<?>>).

Comment by Danilo Tommasina [ 07/Nov/11 ]

Hi Andrew, I'll be out of office for a few days, however I can confirm that it has to do with circles in the generics definition. E.g.:
MyClass implements MyIntf1<MyClass2>

MyClass2 implements MyIntff2<MyClass1>

Comment by Andy Clement [ 07/Nov/11 ]

I'd like to see the 'bottom' of the stack trace, if you have it? (to see why toString() is even being invoked in the first place). Whilst it is possible to fixup toString() I wonder if there is a more subtle issue here and the generics have been constructed incorrectly (we know there are issues in this area). I tried to create a simple project based on your snippets but it all works fine for me. If you had a simple project that exhibited the same problem, that would be great.

Comment by Danilo Tommasina [ 08/Nov/11 ]

Adding following code to a groovy script will start producing errors (for autocompletion, on-mouse-over javadoc, ...)

public OpRiskEventRev getEvRev() {
    return null;
}

Where OpRiskEventRev is defined as:

public class OpRiskEventRev implements PersistentRevision<OpRiskEvent> {
   //...
}

and the rest is defined as:

public class OpRiskEvent implements PersistentNodeRef<OpRiskEventRev> {
   //...
}

public interface PersistentNodeRef<P extends PersistentRevision<? extends PersistentNodeRef<P>>> {
   //...
}

public interface PersistentRevision<N extends PersistentNodeRef<? extends PersistentRevision<N>>> {
   //...
}

Here the full error message (it doesn't really contain more information):

eclipse.buildId=M20110909-1335
java.version=1.6.0_26
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product -data /home/dtommasina/workspace

This is a continuation of log file /export/home/dtommasina/workspace/.metadata/.bak_0.log
Created Time: 2011-11-08 09:15:51.724

Error
Tue Nov 08 10:43:27 CET 2011
An internal error occurred during: "Requesting Java AST from selection".

java.lang.StackOverflowError
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1264)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
	at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1271)
	at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1246)
Comment by Andy Clement [ 08/Nov/11 ]

thanks for the testcode, here is the line that triggers the stack trace. The assert fails and in constructing the message we get the stack overflow.

Line 508 in VariableScope.

Assert.isLegal(typeToParameterize.redirect() != typeToParameterize,
  "Error: trying to resolve type parameters of a type declaration: " + typeToParameterize);
Comment by Andrew Eisenberg [ 15/Mar/12 ]

Andy, what's the status on this bug? Is it safe to close?

Comment by Andy Clement [ 15/Mar/12 ]

still an issue, I just tried it - although slightly different stack trace. let me take another look.

Comment by Andy Clement [ 15/Mar/12 ]

stackoverflow fixed (in 1.8). Groovy included a recent fix to address the simple case that avoided this kind of circular reference A->B->A->B but it doesn't handle the further case A->B->C->A->B->C.





[GRECLIPSE-1233] Renaming a method that has a parameter with a default value doesn't work Created: 03/Nov/11  Updated: 18/Jan/12  Resolved: 15/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser, Refactoring, Search
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Rick Jensen Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7
Eclipse vIndigo Service Release 1, Build id: 20110916-0149
SpringSource Tool Suite Version: 2.8.0.SNAPSHOT Build Id: 201110310726
SpringIDE Version: 2.8.0.201110302204-CI-B1319
Groovy-Eclipse plugin Version: 2.6.0.xx-20111028-1400-e37


Issue Links:
Related
is related to GRECLIPSE-1256 Use a classfile attribute in the clas... Open
Number of attachments : 0

 Description   

When attempting to rename a method with a parameter that has a default value, the rename does not work correctly. Here is the before and after code:

Before
class Summer {
	def sumWithDefaults(a, b, d=0){
		return a + b + d
	}
}

def summer = new Summer()

assert 2 == summer.sumWithDefaults(1,1)
assert 3 == summer.sumWithDefaults(1,1,1)
After
refactoredSumlass Summer {
	def sumWithDefaults(a, b, d=0){
		return a + b + d
	}
}

def summer = new Summer()

assert 2 == summer.refactoredSum(1,1)
assert 3 == summer.sumWithDefaults(1,1,1)

This is the expected result:

Expected
class Summer {
	def refactoredSum(a, b, d=0){
		return a + b + d
	}
}

def summer = new Summer()

assert 2 == summer.refactoredSum(1,1)
assert 3 == summer.refactoredSum(1,1,1)

These are the specific problems observed:

  1. The new method name replaces the first character in the file
  2. The new method name does not actually replace the old method name in the method declaration
  3. Not all method calls with the old name and a matching signature are refactored
    • Only method calls who's call signature matches the parameters with no default value are updated


 Comments   
Comment by Andrew Eisenberg [ 03/Nov/11 ]

This problem happens because of the way that we represent methods with default values internally. Each variant of the method is represented as a new method, but with a source location of [0,1]. It looks like the rename is attempting to change the name of the declaration of the default method, but since it doesn't exist, it winds up replacing the first char of the file with the new name.

Comment by Andrew Eisenberg [ 03/Nov/11 ]

Also need to work on find occurrences and search for methods with default values.

Comment by Andrew Eisenberg [ 11/Nov/11 ]

Fundamentally, this problem is with source locations. I need to found out why the source location for the synthetic variant of the method has invalid values.

Comment by Andrew Eisenberg [ 11/Nov/11 ]

OK. I was able to fix the initial source location problem. And the remaining part is to be able to map method references that take advantage of defaults to their actual definition.

Comment by Andrew Eisenberg [ 12/Nov/11 ]

Fix the second part where we go looking for method declarations based on references. Essentially, for each potential match, we need to search through all other methods of the same name for the original method variant (ie- the method that is actually declared instead of the synthetic ones that use defaults).

This solution is a bit less satisfying because a better way would be to store a back reference in each MethodNode to the original method variant. This would be a much faster check, but it would also require making our patch of the groovy compiler bigger and adding a field that is only needed for the IDE and this would be something hard to feed back into groovy core.

Comment by Andrew Eisenberg [ 15/Nov/11 ]

Fixed and committed with regression tests. I added a method inside of MethodNode called getOriginal(). This method returns the MethodNode corresponding to the one where no default methods have been applied. It is a much simpler solution than the one I had implemented earlier.





[GRECLIPSE-1232] Better content assist for methods with closure arguments Created: 02/Nov/11  Updated: 24/Nov/11  Resolved: 24/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Minor
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by GRECLIPSE-1259 Make parameter guessing content assis... Resolved
is superceded by GRECLIPSE-1262 Auto-add curly brace after closure de... Resolved
Number of attachments : 0

 Description   

Currently, applying a content assist proposal for a method that has a closure argument will do something like this:

myMethodCall null

And the user will have to enter '{', press enter, and then the closure will automatically be terminated with the closing } placed at the correct location.

We could do better here and do something like this (where '|' is the resulting cursor location):

myMethodCall {
    |
}

The difficulty will be twofold:

  1. ensuring that the resulting cursor is placed one indent-level past the indentation of the method call
  2. ensuring that the closing '{' is also placed at the correct indent level.

Not impossible, but there is currently no mechanism to check this inside of our content assist infrastructure.



 Comments   
Comment by Andrew Eisenberg [ 24/Nov/11 ]

Closing this bug as a duplicate since the work covered here has been or will be shortly fixed in GRECLIPSE-1262 and GRECLIPSE-1259.

Now, for closure arguments, null will never be proposed. Instead, an opeening curly brace will be proposed:

myMethodCall {|

And when the user presses enter, the rest of the closure will be filled in:

myMethodCall {
    |
}

Just need to add some testing and will close GRECLIPSE-1259.





[GRECLIPSE-1230] Should warn if project does does not use the JDT compiler Created: 31/Oct/11  Updated: 06/Dec/11  Resolved: 06/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

On occasion, some developers try to convert a groovy project into an AspectJ project or a Scala project. This is not supported since the groovy compiler integration requires the patch org.eclipse.jdt.core plugin to be used to compile the code. If this is detected, we should raise a warning.



 Comments   
Comment by The Alchemist [ 31/Oct/11 ]

Thanks Andrew, you're awesome!

Comment by Andrew Eisenberg [ 06/Dec/11 ]

I have committed a fix for this that will show errors on all files sent to the compiler. The error will read:

Error compiling Groovy project. Either the Groovy-JDT patch is not installed or JavaBuilder is not being used.

Is this sufficient for you?

I have tested this with a Groovy-AspectJ project and when the JDT patch is not installed. The errors appear and then go away when the problem is fixed.

I have not tested on scala projects.





[GRECLIPSE-1229] Code select support for field references in constructor calls with named arguments Created: 31/Oct/11  Updated: 26/Jan/12  Resolved: 26/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine, Search
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Copied from: https://issuetracker.springsource.com/browse/STS-2241

possibly a wish

here:

def song2= new Song(title:"abc",artist:"xyz",duration:0) 

might be nice to have javadoc hovers for 'title', etc. and navigation to jump to them in the domain class.

=======

Although the above description is about Grails domain classes. The solution is generic and could/should be available for all similar calls to synthetic constructors. This would be a nice thing to have, but should work on content assist for these kinds of constructors first.



 Comments   
Comment by Andrew Eisenberg [ 26/Jan/12 ]

See if we can get this done for 2.6.1.

Comment by Andrew Eisenberg [ 26/Jan/12 ]

Not bad...turned out to be a fairly simple fix. Now, for each constructor call, the inferencing engine remembers the type of the call if the call is instantiated using a map. In this case, the map is handled slightly differently than in a normal visit. The key expressions are visited as a field, if it correctly maps to a field.





[GRECLIPSE-1228] code assist for generated ctors that take a Map Created: 31/Oct/11  Updated: 18/Jan/12  Resolved: 22/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

From https://issuetracker.springsource.com/browse/STS-2232

This is quite frustrating when writing grails tests:

new Song(Ctrl+Space)

I'm not sure what I want to see but in my case there are 3 domain class properties that need setting:

new Song(artist:...,title:...,duration:...)


 Comments   
Comment by Andrew Eisenberg [ 22/Nov/11 ]

I have a fix and lots of regression tests. I will commit. I think that this will break some tests on the build server, but I will pick up the pieces when I know what needs to be picked up.

I did a lot of work on fixing some problems with constructor content assist. There is more work to do with cleaning up parameter guessing, but this has nothing to do with constructor content assist, so I will resolve this issue.





[GRECLIPSE-1227] DSLD files found inside of classpath containers not always found Created: 28/Oct/11  Updated: 18/Jan/12  Resolved: 28/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Copied from:
https://issuetracker.springsource.com/browse/STS-2210

Classpath containers are initiailized asynchronously. However, the RefreshDSLDJob runs immediately after a project is created. The raw classpath is correct, but containers may not yet be up to date. The DSLDs are not notified to be refreshed again and so some DSLDs may go missing until explicitly refreshed by the user.

The solution is to use an IElementChangedListener to listen for changes to the Java Model.



 Comments   
Comment by Andrew Eisenberg [ 28/Oct/11 ]

This problem is more general than the STS bug linked to above. However, the fix I have appears to address everything. Committing now.





[GRECLIPSE-1226] Convert to closure/method should be available from refactoring menu Created: 28/Oct/11  Updated: 16/Jan/12  Resolved: 03/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Quick fix/assist
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Minor
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File GRECLIPSE-1226.diff     Text File GRECLIPSE-1226-final.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

We should add menu commands for convert to method and convert to closure quickfixes.



 Comments   
Comment by Andrew Eisenberg [ 01/Dec/11 ]

Expecting patch, but it never came. Won't fix for 2.6.0.

Comment by Geoff Denning [ 05/Dec/11 ]

Still working on the patch - hope to have it ready in a week or so...

Comment by Andrew Eisenberg [ 06/Dec/11 ]

OK. The cut off to put this patch into 2.6.0 is Wednesday. After that, it will be released into 2.6.1 probably in February.

Comment by Geoff Denning [ 10/Dec/11 ]

Patch attached. This is my first contribution so be gentle.

Things I like about the patch:

  • It refactors out the existing quickfix code into a reusable class.
  • The menu actions are added to the standard "Refactor" menu instead of a new top-level menu.

Things I don't like about the patch:

  • It moves the "Refactor" menu to the right of the "Run" menu instead of it's usual location. (I couldn't figure out how to fix this.)
  • The "ConvertToClosureRefactoring" and "ConvertToMethodRefactoring" classes should extend "Refactoring" and implement the refactoring classes properly.
  • The menu options are enabled even if the cursor is on an invalid part of the code (this is probably not a big deal).

Additional criticisms welcome.

Comment by Andrew Eisenberg [ 10/Dec/11 ]

Thanks for the patch. This is a bit larger than I thought it would be. I'll have to take a closer look to see why it is and if there is anything that can be trimmed.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Having a look at this patch now.

The concerning thing is that you redefined the Refactor menu inside of org.codehaus.groovy.eclipse.ui. I wonder what would happen if other third parties try to contribute to that menu. I guess it is less of a big deal since you only redefine the menu inside of a groovy editor.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

On a deeper look, it seems like things are a bit odd. The menu separators in the Java Refactoring menu are missing and all elements are in one big group. I'm not sure a way around this. We may have to remove the menu items.

I also added the refactorings to the context menu when inside of a Groovy Editor. And I added keyboard commands: Alt+G M (for convert to method) and Alt+G F (for convert to closure (field)) (Alt+G C was already taken and all groovy and grails related commands must start with Alt+G).

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Also, changes to ensure that menu items are disabled if the selection is not correct.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Here is the final patch I am committing. In the end, I decided to remove the entries from the refactoring menu. As long as they are available from the Groovy Refactor context menu and there is a keyboard command, that is sufficient.

The reason why you are having trouble contributing to the Refactor menu is that this menu is not populated by normal means through a plugin.xml. Rather, it is populated inside of the JavaEditor and CompilationUnitEditor code. This means that it is largely inaccessible to the platform's extension mechanism.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Fix is committed. Thanks for the original patch.

Comment by Geoff Denning [ 05/Jan/12 ]

Thanks for the explanation Andrew. Yes, getting the menu to work was really problematic. Looking forward to the next hack-a-thon!





[GRECLIPSE-1225] Convert to closure and convert to method Quick assists Created: 28/Oct/11  Updated: 18/Jan/12  Resolved: 28/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Should implement convert method to closure and convert closure to method quick fixes.



 Comments   
Comment by Andrew Eisenberg [ 28/Oct/11 ]

Now available. Committed with regression tests.





[GRECLIPSE-1224] Incorrect inferencing of non-static reference Created: 26/Oct/11  Updated: 18/Jan/12  Resolved: 24/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
depends upon GRECLIPSE-1261 Defined DSLD does not work in static ... Resolved
Number of attachments : 0

 Description   

bar is thought to be a non-static reference in a static context and is erroneously underlined.

class Spooky {
  def bar
  static main() {
    new Spooky().bar  // bar is underlined
  }
}


 Comments   
Comment by Andrew Eisenberg [ 28/Oct/11 ]

This only happens for DSLDs, so the above works. However, in this case:

DSLD file:

 currentType("Spooky").accept {
   property name : 'bar'
 }

Groovy file

class Spooky {
  static main() {
    new Spooky().bar  // bar is underlined
  }
}

This is something about how DSLDs interpret static, not regular references.

Comment by Andrew Eisenberg [ 28/Oct/11 ]

See DSLContributionGroup method and property.

Comment by Andrew Eisenberg [ 24/Nov/11 ]

This bug was just reported by someone else and I fixed it.

See GRECLIPSE-1261.





[GRECLIPSE-1222] m2e configurator will add new classpath entries to the end of the classpath, rather than the beginning Created: 26/Oct/11  Updated: 18/Jan/12  Resolved: 24/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The m2e configurator should be adding the extra source folders to the top of the classpath instead of the end.



 Comments   
Comment by Andrew Eisenberg [ 24/Nov/11 ]

fix and committed.





[GRECLIPSE-1221] Groovy tests in src/test/groovy ignored if no tests in src/test/java Created: 20/Oct/11  Updated: 13/Dec/11  Resolved: 13/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: The Alchemist Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: groovy, groovy-eclipse-compiler, maven3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive groovy.tests.ignored.zip    
Testcase included: yes
Number of attachments : 1

 Description   

Steps to Reproduce

1. Extract the attachment.
2. Run mvn test

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
There are no tests to run.

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

3. See that src/test/groovy/com/kp/BuildInfoTest.groovy exists, and be confused

Workaround

Simply move src/test/groovy/com/kp/BuildInfoTest.groovy to src/test/java/com/kp/BuildInfoTest.groovy

(The test will fail, but that's irrelevant for this. It just points out the fact that the test actually ran.)



 Comments   
Comment by Andrew Eisenberg [ 20/Oct/11 ]

I can confirm the bug. However, there does not need to be a test in src/test/java. Any file will do: a Java file, a text file, etc.

Comment by The Alchemist [ 21/Oct/11 ]

@Andrew: Thank you!

If you point me in the right direction, I'll send over a patch!

Comment by Andrew Eisenberg [ 21/Oct/11 ]

A patch would be great since I won't be able to get to this for at least a couple of weeks. Here is the svn url:
https://svn.codehaus.org/groovy/eclipse/trunk/extras/groovy-eclipse-compiler

It is a very straight forward maven compiler plugin. Let me know if you have any questions.

Comment by The Alchemist [ 21/Oct/11 ]

Unfortunately, I'm not familiar with maven compiler plugins. It would help me get a patch out much faster if you could at least send me a class name. If not, that's ok too.

Thanks, Andrew!

Comment by Andrew Eisenberg [ 21/Oct/11 ]

There is one class in the compiler plugin. All it does is gather up the right configuration to send to the batch compiler. Here is the svn link to the file:

https://svn.codehaus.org/groovy/eclipse/trunk/extras/groovy-eclipse-compiler/src/main/java/org/codehaus/groovy/eclipse/compiler/GroovyEclipseCompiler.java

Comment by The Alchemist [ 22/Oct/11 ]

@Andrew: Thanks... turns out the issue is deeper in the internals of Maven. GroovyEclipseCompiler passes "" as the inputFileEnding it wants to AbstractCompiler but that setting is never used, by anything.

If you don't put a blank resource, etc. into src/test/java, the TestCompilerMojo never gets invoked so GroovyEclipseCompiler never gets called for target/test-classes.

Unfortunately, I don't know enough Maven to try to debug this one.

WORKAROUND

touch src/test/java/i.am.blank

Comment by Andrew Eisenberg [ 22/Oct/11 ]

There is another workaround, to use the build-helper plugin and specify the extra test folder explicitly using the add-test-source goal. However, that is something that I tried to avoid when I created the compiler plugin. I didn't want any extra configuration.

I don't know that much about maven plugins either, but it might be possible for the groovy-eclipse-compiler plugin to call the build-helper-plugin with the appropriate goal in order to add the test source folder.

Comment by The Alchemist [ 23/Oct/11 ]

@Andrew: I'm not sure if groovy-eclipse-compiler can call build-helper-plugin because it doesn't have any Mojo's. But it's definitely worth a try.

Comment by Andrew Eisenberg [ 26/Nov/11 ]

I've been trying to find a clean solution where these source folders are added automatically, but unfortunately, that doesn't seem to be the way that maven works.

The best I could do is to create two simple mojos inside of the groovy-eclipse-compiler plugin that adds the extra source folders, but then this information needs to be explicitly added to the pom.

So, this is what it will look like (but haven't pushed this to any repository yet):

		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>2.3.2</version>
				<configuration>
					<compilerId>groovy-eclipse-compiler</compilerId>
				</configuration>
				<dependencies>
					<dependency>
						<groupId>org.codehaus.groovy</groupId>
						<artifactId>groovy-eclipse-compiler</artifactId>
						<version>2.6.0-01-SNAPSHOT</version>
					</dependency>
				</dependencies>
			</plugin>
			<plugin>
				<groupId>org.codehaus.groovy</groupId>
				<artifactId>groovy-eclipse-compiler</artifactId>
				<version>2.6.0-01-SNAPSHOT</version>
				<executions>
					<execution>
						<id>add-source</id>
						<phase>generate-sources</phase>
						<goals>
							<goal>add-groovy-source</goal>
						</goals>
					</execution>
					<execution>
						<id>add-test-source</id>
						<phase>generate-test-sources</phase>
						<goals>
							<goal>add-groovy-test-source</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
		</plugins>

It works, but it is annoying and not much better than using the build-helper-maven-plugin. I'd like to not have to include this extra cruft in the pom and call the new mojos implicitly. @Alchemist, do you have any experience with this?

Comment by The Alchemist [ 26/Nov/11 ]

@Andrew:
Sorry, don't have any experience with that. But at least now we have a Maven workaround.

Comment by Andrew Eisenberg [ 02/Dec/11 ]

So, there are 4 workarounds, but none of them make me happy. I have been chatting with the folks at the maven users mailing list, but still nothing great.

  1. Add an empty file to your java source folders
  2. Use the build-helper-maven-plugin
  3. Use groovy-eclipse-compiler as I describe two comments ago (this part is not committed yet, but it works for me locally). This solution uses less configuration than the previous one, but is still 21 lines of configuration (about 6 fewer lines than the other solution).
  4. Move your Groovy code to Java source folders

I'm just a bit disappointed that maven requires explicit configuration for anything that deviates from the normal. I think I will close this bug and completely describe all workarounds on the wiki.

Comment by The Alchemist [ 02/Dec/11 ]

@Andrew: Thanks for doing the legwork. Yeah, that configuration stinks...

Comment by Andrew Eisenberg [ 08/Dec/11 ]

After much work, and a question on stack overflow, I have made significant progress.

I now have a mojo that works quite nicely to add the source folders to the build. It is a lot of configuration to do a very simple thing, but at least it is hidden from the downstream developer. I will push out a snapshot of this.

Comment by The Alchemist [ 08/Dec/11 ]

@Andrew: Don't hesitate to shout and I'll give the snapshot a try.

Comment by Andrew Eisenberg [ 09/Dec/11 ]

Thanks. Just deployed 2.6.0-01-SNAPSHOT to http://nexus.codehaus.org/snapshots/. If you want to use it in projects that have nothing in the java source and test folders, then do this in the plugins section:

    <plugin>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-eclipse-compiler</artifactId>
        <version>2.6.0-01-SNAPSHOT</version>
        <extensions>true</extensions>
    </plugin>

That last line <extensions>true</extensions> is important since it states that groovy-eclipse compiler will be augmenting the default lifecycle. You will know if it is working if you see something like:

Adding /src/main/groovy to the list of source folders
Adding /src/test/groovy to the list of source folders

in the logs.

So, here's what's going on behind the scenes. I have redefined the lifecycle mappings for the common lifecycles that have a compile phase (jar, war, ejb, maven-plugin) and added an init phase, which calls the simple mojo that I created that adds the extra source folders.

Please let me know if you get a chance to try this out.

Comment by Marc von Renteln [ 12/Dec/11 ]

Tested the SNAPSHOT. It adds the folders correctly and the sources are compiled. Seems to do the same thing that maven-buildhelper-plugin does.

But both solutions seem to add the folder twice for the other maven plugins... I tried to create a maven plugin written in groovy. The source is compiled but the groovy source file is found twice and therefore the generation of the plugin descriptor fails with a "duplicate mojo definition" error message...

I use the default maven-plugin-plugin to generate the descriptor but with a modified extractor:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-plugin-plugin</artifactId>
<version>2.4</version>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo.groovy</groupId>
<artifactId>groovy-mojo-tools</artifactId>
<version>1.0-beta-2</version>
</dependency>
</dependencies>
</plugin>

Don't know if the extractor is wrong here but I wanted to mention it if you would like to test it with this plugin...

The complete code can be found in https://github.com/mvonrenteln/groovy-mojo-example

Comment by Andrew Eisenberg [ 12/Dec/11 ]

So, just to be sure...is the problem that you cannot correctly create this plugin or that you cannot correctly use this plugin?

Comment by Andrew Eisenberg [ 12/Dec/11 ]

Right...it is the former.

I have not created or tested groovy-eclipse-compiler with plugins in mind.

Comment by Andrew Eisenberg [ 12/Dec/11 ]

A workaround — rename src/main/groovy to src/main/java and things work fine.

Comment by Marc von Renteln [ 12/Dec/11 ]

Thanks for your fast reply. I will use the workaround. My intention was to show this problem with other plugins...

Comment by Andrew Eisenberg [ 12/Dec/11 ]

The problem is in groovy-mojo-tools. The class GroovyMojoDescriptorExtractor, line 71. It is adding src/main/groovy a second time even if it already exists. There is a section:

        //
        // FIXME: Shouldn't need to hard-code this...
        //
        sourceRoots.add("src/main/groovy");

And the comment is correct. This shouldn't be hardcoded. At the very least, the check should see if src/main/groovy is already on the path and if so, not add it a second time.

As you said, you don't know who maintains this plugin. I would recommend forking the plugin for now and seeing if you can get this to work. Anyway, this bug is different from the bug originally reported in this issue, so if you have any more problems, please raise a new issue.

Comment by Marc von Renteln [ 13/Dec/11 ]

OK, thanks! I will fork the plugin and see what I can do there.

Comment by Andrew Eisenberg [ 13/Dec/11 ]

I've done just about all I can do here. I will update the documentation to describe the various ways of setting up your source folders.

The 2.6.0-01 version has been released.





[GRECLIPSE-1220] Non-working copy Groovy compilation units that use DSLDs not working properly Created: 17/Oct/11  Updated: 18/Jan/12  Resolved: 18/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support, Inferencing Engine
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: dsld
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When there is an inferencing engine invocation on a Groovy Compilation unit that is not a working copy, DSLDs applied to the file cannot resolve type information.

The reason is that when a file is not a working copy, GroovyCompilationUnit.getResolver() will always return null.

I need to change the way that the GroovyDSLDContext is created. Currently, a compilation unit is passed in and the ModuleNode and JDTResolver is extracted from it. But, if the unit is not a working copy, the resolver will be null. Instead, the module node and resolver should be created elsewhere and passed into the constructor.



 Comments   
Comment by Andrew Eisenberg [ 18/Oct/11 ]

Fix now committed. I refactored ModuleNodeMapper and GroovyCompilationUnit so that the ModuleNode and the JDTResolver can be retrieved together if requested.





[GRECLIPSE-1219] Annotations on import statements are removed after organize imports is called Created: 13/Oct/11  Updated: 09/Jan/13  Resolved: 03/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Formatting
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: John Bäckstrand Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: grab
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GRECLIPSE-1390 Organize Imports does not sort by typ... Resolved
Number of attachments : 0

 Description   

I use a workspace config that has "Organize imports" set as a save action for Java. This seems to immediately remove any @Grab lines from the begining of the groovy scripts as soon as I save them. If i put the line after my imports, I get an error instead:

!ENTRY org.eclipse.jdt.ui 4 10006 2011-10-13 10:10:34.836
!MESSAGE The save participant 'org.eclipse.jdt.ui.postsavelistener.cleanup' caused an exception: java.lang.NullPointerException
!STACK 0
java.lang.NullPointerException
at org.codehaus.groovy.eclipse.refactoring.actions.GroovyImportsCleanUp.createFix(GroovyImportsCleanUp.java:61)
at org.eclipse.jdt.internal.corext.fix.CleanUpRefactoring.calculateChange(CleanUpRefactoring.java:803)
at org.codehaus.groovy.eclipse.refactoring.actions.CleanUpPostSaveListener.saved(CleanUpPostSaveListener.java:350)
at org.codehaus.groovy.eclipse.refactoring.actions.DelegatingCleanUpPostSaveListener.saved(DelegatingCleanUpPostSaveListener.java:120)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$5.run(CompilationUnitDocumentProvider.java:1590)
...



 Comments   
Comment by John Bäckstrand [ 13/Oct/11 ]

Actually, the error might not be so important since I put the annotation in an invalid position. If I put it on a class after my imports everything works properly!

This works:

import static groovyx.net.http.ContentType.*
import static groovyx.net.http.Method.*

import java.security.*
import java.security.interfaces.*

import javax.crypto.Cipher
import javax.xml.bind.DatatypeConverter

import groovyx.net.http.*
@Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.5.1' )
public class sh{}

println "doh"

Whereas this doesn't:

@Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.5.1' )
import static groovyx.net.http.ContentType.*
import static groovyx.net.http.Method.*

import java.security.*
import java.security.interfaces.*

import javax.crypto.Cipher
import javax.xml.bind.DatatypeConverter

import groovyx.net.http.*
public class sh{}

println "doh"
Comment by Andrew Eisenberg [ 13/Oct/11 ]

The NPE that you see has been fixed with GRECLIPSE-1217. But, there is a new issue that you have uncovered. It looks like annotations are removed from import statements after an organize imports. I have changed the title to reflect the new problem.

Just to be sure...after placing the annotation on the class declaration, you are no longer having any problems?

Comment by John Bäckstrand [ 13/Oct/11 ]

Yes, that is what I am seeing.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Fixed two related problems here:

  • No hovers or navigation for annotations on imports
  • No find occurrences either

Both were easy fixes. Unfortunately, fixing organize imports is not simple. We have inherited most of the organize imports code from JDT. The JDT behavior is to strip everything except for the type name from imports after organizing.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Actually...ha! This did turn out to be easy. It turns out that there are different ways of configuring the ImportRewriter. One way keeps old imports and another way removes them. For organize imports, JDT configures it the second way as does Groovy-Eclipse. But, if Groovy-Eclipse changes to the first way, then nothing appears to break and comments are kept as expected.

All tests are still passing and I created a few regression tests for the new functionality (including the other fixes mentioned in my previous comment).

Comment by Andrew Eisenberg [ 03/Jan/12 ]

committed the fix.





[GRECLIPSE-1218] Syntax highlighter is confused by a slashy string composited from substrings and ended by a final "/$/" Created: 12/Oct/11  Updated: 12/Oct/11  Resolved: 12/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Minor
Reporter: David Tonhofer Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux / Eclipse Version: 3.6.1


Attachments: PNG File Syntax.png    
Issue Links:
Duplicate
duplicates GRECLIPSE-1203 Syntax highlight for slashed strings Resolved
Number of attachments : 1

 Description   

We want to composite slashed strings from substrings:

import java.util.regex.Pattern;

public class Syntax {
    
    private final static String OPTIONALLY_SIGNED_INT = /((\+|\-)?(\d+))/
    private final static String OPTIONALLY_NEG_INT = /((\-)?(\d+))/
    private final static String SIGNED_INT = /((\+|\-)(\d+))/
    
    private final static Pattern PAT_T1 = ~(/^/ + OPTIONALLY_SIGNED_INT + /((X|x)*)$/)
    private final static Pattern PAT_T2 = ~(/^/ + OPTIONALLY_SIGNED_INT + /\s*(<|<=|=<|>|>=|=>|\-|\.\.|\.\.\.|&#8804;|&#8805;)$/)
    private final static Pattern PAT_T3 = ~(/^(<|<=|=<|>|>=|=>|\.\.|\.\.\.|&#8804;|&#8805;)\s*/ + OPTIONALLY_SIGNED_INT + /$/)
    private final static Pattern PAT_T3X = ~(/^(\-)\s*/ + SIGNED_INT  + /$/) // special case of T3integer
    private final static Pattern PAT_T3XX = ~(/^(\-)\s+/ + OPTIONALLY_NEG_INT + /$/) // special case of T3
    private final static Pattern PAT_T4 = ~(/^/ + OPTIONALLY_SIGNED_INT + /\s*(,|\.\.|\.\.\.)\s*/  + OPTIONALLY_SIGNED_INT + /$/)
    private final static Pattern PAT_T4X = ~(/^/ + OPTIONALLY_SIGNED_INT + /\s*(\-)\s*/ + SIGNED_INT + /$/) // special case of T4
    private final static Pattern PAT_T4XX = ~(/^/ + OPTIONALLY_SIGNED_INT + /\s*(\-)\s+/ + OPTIONALLY_NEG_INT + /$/) // special case of T4
    
 }

The /$/ confuses the syntax highlighter. It seems to think this has something to do with a variable maybe?

See attachment for the highlighting. There are no compiler errors and the associated program passes testcases.



 Comments   
Comment by Andrew Eisenberg [ 12/Oct/11 ]

Unfortunately, this is a tough problem. Slashy string detection is performed using regular expressions on the text (for performance reasons). But, there are times when there are open and close slashy string delimiters in the text for other reasons.

One possibility is to completely remove slashy string highlighting.





[GRECLIPSE-1217] NPE during organize import save action w/broken code Created: 12/Oct/11  Updated: 18/Jan/12  Resolved: 12/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: GubeSpam Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Java EE for Web Developers / Indigo release, WinXP


Number of attachments : 0

 Description   

I am getting this on version groovy plugin version 2.5.2.xx-20110907-1400-e37, with Eclipse Java EE for Web Developers / Indigo release.

This is occurring when saving my groovy file, which is below. Notice: the groovy code has a syntax error in it, but I don't think the save action should blow up like this as a result.

Might be related to GRECLIPSE-735?

public class CopyOfMappingScriptService
{
    def myMethod(){
        def map = [:]
        [].each{ 
            if( true ){
                map[1] = 
            }
        }
        return null
    }
}

Stacktrace:

java.lang.NullPointerException
at org.codehaus.groovy.eclipse.refactoring.actions.GroovyImportsCleanUp.createFix(GroovyImportsCleanUp.java:61)
at org.eclipse.jdt.internal.corext.fix.CleanUpRefactoring.calculateChange(CleanUpRefactoring.java:803)
at org.codehaus.groovy.eclipse.refactoring.actions.CleanUpPostSaveListener.saved(CleanUpPostSaveListener.java:350)
at org.codehaus.groovy.eclipse.refactoring.actions.DelegatingCleanUpPostSaveListener.saved(DelegatingCleanUpPostSaveListener.java:120)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$5.run(CompilationUnitDocumentProvider.java:1590)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.notifyPostSaveListeners(CompilationUnitDocumentProvider.java:1585)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.commitWorkingCopy(CompilationUnitDocumentProvider.java:1379)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$4.execute(CompilationUnitDocumentProvider.java:1450)
at org.eclipse.ui.editors.text.TextFileDocumentProvider$DocumentProviderOperation.run(TextFileDocumentProvider.java:132)
at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:456)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument(TextFileDocumentProvider.java:772)
at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5048)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSave(CompilationUnitEditor.java:1247)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave(CompilationUnitEditor.java:1301)
at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7177)
at org.eclipse.ui.Saveable.doSave(Saveable.java:214)
at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:349)
at org.eclipse.ui.internal.SaveableHelper$3.run(SaveableHelper.java:195)
at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:277)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756)
at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2642)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:285)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:264)
at org.eclipse.ui.internal.SaveableHelper.saveModels(SaveableHelper.java:207)
at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:144)
at org.eclipse.ui.internal.EditorManager.savePart(EditorManager.java:1399)
at org.eclipse.ui.internal.WorkbenchPage.savePart(WorkbenchPage.java:3416)
at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3429)
at org.eclipse.ui.internal.handlers.SaveHandler.execute(SaveHandler.java:54)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1509)
at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640)
at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4528)
at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2530)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)



 Comments   
Comment by Andrew Eisenberg [ 12/Oct/11 ]

No. You're right. There should not be an NPE here. There's probably not much we can do about actually performing the correct organize imports operation since the file is not parseable.

Comment by Andrew Eisenberg [ 12/Oct/11 ]

Fix committed. There was a status object that was not initialized in the particular path that occurred during the save action of this particular code. I now ensure that it is always properly initialized.

Fix may not be available until tomorrow since we are currently having some test failures on the build server.

Thanks for reporting.





[GRECLIPSE-1216] Groovy Eclipse plugin stops reformatting of some Java files in Java projects Created: 11/Oct/11  Updated: 18/Jan/12  Resolved: 11/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Critical
Reporter: Andrew Johnson Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Eclipse 3.7, Eclipse IDE for Java EE Developers 1.4.0.20110615-0550


Attachments: Java Source File OQLParserTokenManager.java    
Number of attachments : 1

 Description   

The Groovy Eclipse plugin seems to stop some pure Java files in Java projects from being reformatted.

The reformatting fails silently and the file is unchanged.

The file reformats correctly before Groovy Eclipse is installed.
The file does not reformat after Groovy Eclipse is installed.
The file reformats correctly after Groovy Eclipse is uninstalled.

I discovered this while developing Eclipse Memory Analyzer Tool and regenerating some Javacc code, then attempting to reformat the generated Java code.

Other files do reformat correctly, and by cutting the file down reformatting will occur, but I don't know what triggers the problem.



 Comments   
Comment by Andrew Eisenberg [ 11/Oct/11 ]

I can confirm that this file cannot be reformatted inside of Eclipse with Groovy-Eclipse installed. I haven't confirmed that Groovy-Eclipse is causing the problem. Bumping up priority.

Comment by Kris De Volder [ 11/Oct/11 ]

I've done a bit of exploration with the debugger. Not yet got to the bottom of things, but it is plausible/likely that Greclipse JDT patch is responsible.

I've tracked down the control flow where the behavior differs from the correct behavior to the method

org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(int, String, int, int, int, String)

This method is returning null for the sample Java file attached to this issue but it returning a real edit when formatting a simpler Java file.

The method in question lives inside the jdt patch so it is likely that JDT patch is containing an outdated or buggy version of the method.

Comment by Kris De Volder [ 11/Oct/11 ]

This swallowed exception seems responsible for the 'null' being returned:

org.eclipse.jdt.internal.formatter.AbortFormatting: unexpected token type, expecting:2, actual:48
	at org.eclipse.jdt.internal.formatter.Scribe.printNextToken(Scribe.java:4898)
	at org.eclipse.jdt.internal.formatter.Scribe.printNextToken(Scribe.java:4889)
	at org.eclipse.jdt.internal.formatter.Scribe.printNextToken(Scribe.java:4885)
	at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:4265)
	at org.eclipse.jdt.internal.compiler.ast.LongLiteral.traverse(LongLiteral.java:161)
	at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:2765)
	at org.eclipse.jdt.internal.compiler.ast.ArrayInitializer.traverse(ArrayInitializer.java:216)
	at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:663)
	at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.formatTypeMembers(CodeFormatterVisitor.java:2206)
	at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:1218)
	at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:5591)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:1273)
	at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.visit(CodeFormatterVisitor.java:3314)
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.traverse(CompilationUnitDeclaration.java:659)
	at org.eclipse.jdt.internal.formatter.CodeFormatterVisitor.format(CodeFormatterVisitor.java:864)
	at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.formatCompilationUnit(DefaultCodeFormatter.java:241)
	at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:163)
	at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:146)
	at org.eclipse.jdt.internal.corext.util.CodeFormatterUtil.reformat(CodeFormatterUtil.java:288)
	at org.eclipse.jdt.internal.ui.text.java.JavaFormattingStrategy.format(JavaFormattingStrategy.java:67)
	at org.eclipse.jface.text.formatter.MultiPassContentFormatter.formatMaster(MultiPassContentFormatter.java:193)
	at org.eclipse.jface.text.formatter.MultiPassContentFormatter.format(MultiPassContentFormatter.java:135)
	at org.eclipse.jface.text.source.SourceViewer.doOperation(SourceViewer.java:977)
	at org.eclipse.jface.text.source.projection.ProjectionViewer.doOperation(ProjectionViewer.java:1534)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.doOperation(JavaSourceViewer.java:191)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:200)
	at org.eclipse.ui.texteditor.TextOperationAction$1.run(TextOperationAction.java:128)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.texteditor.TextOperationAction.run(TextOperationAction.java:126)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
	at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
	at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3588)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3209)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Comment by Andy Clement [ 11/Oct/11 ]

thanks for digging Kris, guess I better take a look.

Comment by Kris De Volder [ 11/Oct/11 ]

It looks like this is an Eclipse 3.7.1 regression of sorts. When I use plain Eclipse RCP version 3.7.1 with nothing extra installed the bug also manifests. But it doesn't manifest in Eclipse 3.7.0.

Comment by Kris De Volder [ 11/Oct/11 ]

I think it is this method that's responsible for the bug:

org.eclipse.jdt.internal.compiler.ast.LongLiteral.buildLongLiteral(char[], int, int)

That method is new in 3.7.1 and it makes a special case for constants like "0x8000000000000000L" and its exactly in that case that the formatter breaks because it is somehow trying to print out that constant as a negative integer.

Similar cases also exist in IntLiteral (and likely other numeric signed types that can be written in hex notation).

This is really a Eclipse JDT bug, but we have copied it over into the Greclipse JDT patch.

It is possible that one introduces the bug by installing Greclipse over a copy of Eclipse 3.7.0 which doesn't have the bug (e.g. if installing Greclipse over STS 2.7.0 or pre 2.8.0.M2 you'd get the bug copied from 3.7.1).

Comment by Kris De Volder [ 11/Oct/11 ]

I think I know how to fix it. So will try something out and if it works commit that.

I guess, should also sumbit a bug report to Eclipse.

This is a simple test program that triggers the bug:

public class SimpleClass {
public static final long VERY_SMALL_LONG = 0x8000000000000000L;
public static final long VERY_SMALL_INT = 0x80000000;
}

The bug is triggered by using those very special constants in HEX notation. The formatter mistakenly assumes they are to be printed as negative numbers with a '-' sign and then chokes because it can't actually find the expected sign in the source code.

Test program covers both instances of the bug. I looked at the type hierarchy and don't think there's other cases out there.

Comment by Kris De Volder [ 11/Oct/11 ]

Eclipse bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=360600

Comment by Kris De Volder [ 11/Oct/11 ]

I committed a fix.

Comment by Andy Clement [ 12/Oct/11 ]

Kris, that is nice work. But you did fail to mark the changes in your commit, potentially making it hard for me on next merge when I am trying to pick up the real eclipse fix (I see they have already fixed it for 3.7.2). I've modified the commits to include some markers. I presume there is no testcase as we aren't setup to test things like this?

Comment by Andrew Johnson [ 12/Oct/11 ]

Thank you for the prompt fix. I can confirm that

JDT Core patch for Groovy-Eclipse plugin 2.5.2.xx-20111011-1900-e37 org.codehaus.groovy.jdt.patch.feature.group Codehaus.org

from:

Development builds for Eclipse 3.7 are at:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

fixes the problem for me.





[GRECLIPSE-1215] StackOverflow while editing groovy classes. Created: 10/Oct/11  Updated: 11/Oct/11  Resolved: 11/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Critical
Reporter: Frank Fuller Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse.buildId=M20110210-1200
java.version=1.6.0_26
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -refresh -product org.eclipse.epp.package.jee.product
Command-line arguments: -os win32 -ws win32 -arch x86 -refresh -product org.eclipse.epp.package.jee.product


Attachments: Text File .bak_5.log     File CompareJSON.groovy    
Number of attachments : 2

 Description   

The error is very similar to GRECLIPSE-1116.

Create a groovy file with several class descriptions. Begin editing one of the classes and a stack overflow error occurs. After closing eclipse, attempts to start eclipse result in stack overflow errors.

The attached groovy file is the one that generated the errors. I was editing the ExactString class line 50 when the errors occurred. Try the following steps.

1) Type enter after line 49 – super.run(expectedValue, actualValue)
2) On the new blank line 50 type: if (!TokenCompiler.isKeyWord(expectedValue)) {

The stack overflow is thrown after the open parentheses is typed.

Work around for the error:
1) close eclipse
2) Opening the groovy file in a text editor reveals that the edits were partially saved.
3) Complete the edits in the text editor and save the file.
4) Open eclipse and the stack overflow error no longer occurs.



 Comments   
Comment by Andrew Eisenberg [ 10/Oct/11 ]

It looks to me like you are having a temporary circular class hierarchy. See GRECLIPSE-531. It should have been resolved in 2.5.0, so you may be seeing a new variation of the problem.

I did try your instructions in 2.5.2 and could not reproduce the problem. Could you try updating to 2.5.2 and seeing if you stil have the problem?

Comment by Frank Fuller [ 11/Oct/11 ]

Andrew,

I updated to the 2.52 plugin. Prior to conducting the update, I verified that the error still occurs, and I left the partially edited file in the work space. I upgraded the plugin, restarted eclipse and attempted to open the work space that had the error. The work space opened without the stack overflow and the partially edited file was visible. I completed the edits, saved the file, undid the changes, and attempted to recreate the error. I did not receive the stack overflow error after updating. So, it appears that the bug is fixed in 2.5.2.

Thank you for your very quick assistance in resolving this issue.

Comment by Frank Fuller [ 11/Oct/11 ]

Upgrading to the 2.5.2 version of the plugin resolved the issue.

Comment by Andrew Eisenberg [ 11/Oct/11 ]

Thanks for verifying the fix.





[GRECLIPSE-1214] NullPointerException in JDTResolver.recordDependency Created: 09/Oct/11  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.8.0.Release

Type: Bug Priority: Major
Reporter: Kohsuke Kawaguchi Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version 2.5.2.xx-20111007-1500-e36


Number of attachments : 0

 Description   

If I have a Java class called "org.acme.Foo", then the script file named "org/acme/Foo/xyz.groovy" loses DSLD content assist support.

Looking at the Groovy event console, I see a NullPointerException as below.

The problem appears to be related to the fact that the directory name collides with another Java class, as Groovy files placed elsewhere do not get this problem. Note however that this xyz.groovy file doesn't have a package declaration.

See GRECLIPSE-1076 for a package/class conflict related issue that may or may not be related.

java.lang.NullPointerException
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.recordDependency(JDTResolver.java:316)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromCompileUnit(JDTResolver.java:155)
	at org.codehaus.groovy.control.ResolveVisitor.resolveNestedClass(ResolveVisitor.java:331)
	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:304)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:292)
	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:261)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:303)
	at org.codehaus.groovy.eclipse.dsl.lookup.ResolverCache.resolve(ResolverCache.java:62)
	at org.codehaus.groovy.eclipse.dsl.contributions.DSLContributionGroup.delegatesTo(DSLContributionGroup.java:249)
	at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:362)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
	at eclipse$_run_closure1.doCall(eclipse.dsld:8)
	at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:273)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
	at eclipse$_run_closure1.doCall(eclipse.dsld)
	at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:273)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
	at groovy.lang.Closure.call(Closure.java:282)
	at groovy.lang.Closure.call(Closure.java:277)
	at org.codehaus.groovy.eclipse.dsl.contributions.DSLContributionGroup.getContributions(DSLContributionGroup.java:102)
	at org.codehaus.groovy.eclipse.dsl.DSLDStore.findContributions(DSLDStore.java:132)
	at org.codehaus.groovy.eclipse.dsl.lookup.DSLDTypeLookup.lookupTypeAndDeclaration(DSLDTypeLookup.java:58)
	at org.eclipse.jdt.groovy.search.AbstractSimplifiedTypeLookup.lookupType(AbstractSimplifiedTypeLookup.java:81)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleExpression(TypeInferencingVisitorWithRequestor.java:763)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstantExpression(TypeInferencingVisitorWithRequestor.java:1321)
	at org.codehaus.groovy.ast.expr.ConstantExpression.visit(ConstantExpression.java:55)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1406)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1252)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitClosureExpression(CodeVisitorSupport.java:174)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitClosureExpression(TypeInferencingVisitorWithRequestor.java:1085)
	at org.codehaus.groovy.ast.expr.ClosureExpression.visit(ClosureExpression.java:45)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitListOfExpressions(CodeVisitorSupport.java:280)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitTupleExpression(CodeVisitorSupport.java:178)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitTupleExpression(TypeInferencingVisitorWithRequestor.java:1620)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitArgumentlistExpression(CodeVisitorSupport.java:290)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitArgumentlistExpression(TypeInferencingVisitorWithRequestor.java:907)
	at org.codehaus.groovy.ast.expr.ArgumentListExpression.visit(ArgumentListExpression.java:73)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1426)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1252)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstructorOrMethod(TypeInferencingVisitorWithRequestor.java:646)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:390)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:236)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:191)
	at org.codehaus.groovy.eclipse.editor.highlighting.GatherSemanticReferences.findSemanticHighlightingReferences(GatherSemanticReferences.java:52)
	at org.codehaus.groovy.eclipse.editor.highlighting.GroovySemanticReconciler.reconciled(GroovySemanticReconciler.java:149)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1632)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:161)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:110)
	at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
	at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)


 Comments   
Comment by Andrew Eisenberg [ 09/Oct/11 ]

As a work around, can you try right clicking on the script -> Build Path -> Exclude? Does that at least prevent the NPEs from happening?

Comment by Kohsuke Kawaguchi [ 10/Oct/11 ]

I tried that but it doesn't seem to make any difference, AFAICT.

Comment by Andy Clement [ 10/Oct/11 ]

I was just going to put in a guard for the NPE, but have had second thoughts, it'll just be hiding something else if I do. The assertion that the scope has been set (other code than simple recordDependency relies on the scope being set correctly).

It may well be related to GRECLIPSE-1076. However in a rudimentary attempt to create the problem scenario here, I don't get that NPE shown above, I get a somewhat related but different variant:

Ignoring GroovyBugError since it is likely caused by earlier issues.  Ignored problem is 'BUG! exception in phase 'semantic analysis' in source unit '/Users/aclement/workspaces/grdev_37/JP/src/com/acme/Foo/xyz.groovy' commencingResolution failed: declaration found, but unexpectedly found no scope for com.acme.Foo.xyz'
org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug: commencingResolution failed: declaration found, but unexpectedly found no scope for com.acme.Foo.xyz
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.commencingResolution(JDTResolver.java:578)
	at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1331)
	at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:165)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:626)
	at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:654)
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:915)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:589)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:538)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1523)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:979)
	at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1018)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody0(CompilationUnitProblemFinder.java:218)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process_aroundBody1$advice(CompilationUnitProblemFinder.java:244)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:1)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:284)
	at org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:80)
	at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:410)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
	at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:104)

(which is the same 'no scope' problem but this time caught in time rather than NPE'd upon).

Comment by Andy Clement [ 12/Oct/11 ]

I found a situation where this kind of setup can lead to the missing scope, that is now fixed, should be in a dev build tomorrow. It may alleviate the exceptions shown in this bug. It is a variant of GRECLIPSE-1076 but that one is much more difficult to solve nicely because the script has a package name. Here with no package name we just have to allow the script to be as if declared in the default package.

Comment by Andrew Eisenberg [ 26/Apr/13 ]

Fixed now.





[GRECLIPSE-1213] [Parser] auto-completion not working for BorderLayout constants (CENTER, NORTH, ...) Created: 04/Oct/11  Updated: 02/Nov/11  Resolved: 02/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Minor
Reporter: Roger Talkov Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse 3.6.2, Windows 7


Number of attachments : 0

 Description   

Doesn't work or a line like:
panel.add (textField, BorderLayout.
The CENTER, NORTH,EAST,WEST choices don't show

works for:
BorderLayout.
String s = BorderLayout.
String s = 'foo' + BorderLayout.
but fails for:
String s = ('foo' + BorderLayout.

So it looks like the open paren causes it to fail



 Comments   
Comment by Andrew Eisenberg [ 04/Oct/11 ]

This is a parser recovery problem. The parser is failing to understand the code without the extra paren and so cannot provide any meaningful content assist.

Comment by Andy Clement [ 02/Nov/11 ]

fixed both situations (with groovy 1.8)





[GRECLIPSE-1211] Include all binary dependencies of groovy-all inside of the groovy classpath container Created: 30/Sep/11  Updated: 18/Jan/12  Resolved: 30/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Project Settings, Search
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.6.1.M1

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Some users have noticed that if a very generic search term (such as getName) is used inside of a groovy project, then the search results return way too many 'potential matches'. The reason for this is that there are missing binary dependencies that cause the type hierarchies of many bunary types to be invalid. Any type hierarchy that is invalid will cause matching to occur as a string, rather than using type bindings.

We can fix this by adding all binary dependencies to the classpath container.



 Comments   
Comment by Andrew Eisenberg [ 30/Sep/11 ]

Fixed locally. Will commit after the official release of 2.5.2.





[GRECLIPSE-1208] JDI Event Dispatch error when trying to step into or over code in groovy classes Created: 25/Sep/11  Updated: 26/Sep/11  Resolved: 26/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Critical
Reporter: Zahir Toufie Assignee: Unassigned
Resolution: Fixed  
Labels: debugging
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora 15 x86_64, Eclipse 3.6.2 for Linux GTK x86_64, Groovy-Eclipse Feature 2.5.2.xx-20110921-1500-e36


Number of attachments : 0

 Description   

I completely re-installed Eclipse 3.6.2 together with the SpringSource STS plugins over the weekend and tried debugging an existing workspace of mine which I created earlier in the month.

For some reason I get the following error as per the eclipse workspace .metadata/.log file whenever I try and step over or into any groovy classes/code lines.

!ENTRY org.eclipse.core.jobs 4 2 2011-09-26 10:04:59.659
!MESSAGE An internal error occurred during: "JDI Event Dispatch".
!STACK 0
java.lang.AbstractMethodError: com.springsource.sts.groovy.debug.core.GroovyDebugProvider.isAlwaysInteretingLaunch()Z
at org.eclipse.contribution.jdt.debug.DebugHooksAspect.isInterestingLaunch(DebugHooksAspect.aj:253)
at org.eclipse.contribution.jdt.debug.DebugHooksAspect.ajc$inlineAccessMethod$org_eclipse_contribution_jdt_debug_DebugHooksAspect$org_eclipse_contribution_jdt_debug_DebugHooksAspect$isInterestingLaunch(DebugHooksAspect.aj:1)
at org.eclipse.jdt.internal.debug.core.model.JDIThread$StepHandler.locationShouldBeFiltered_aroundBody1$advice(JDIThread.java:81)
at org.eclipse.jdt.internal.debug.core.model.JDIThread$StepHandler.locationShouldBeFiltered(JDIThread.java:1)
at org.eclipse.jdt.internal.debug.core.model.JDIThread$StepHandler.handleEvent(JDIThread.java:2168)
at org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch(EventDispatcher.java:155)
at org.eclipse.jdt.internal.debug.core.EventDispatcher.access$0(EventDispatcher.java:104)
at org.eclipse.jdt.internal.debug.core.EventDispatcher$1.run(EventDispatcher.java:250)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

My current Groovy-Eclipse Feature is 2.5.2.xx-20110921-1500-e36. Yes that is correct. Strange 2.5.2 is only due for relase this Friday so not sure why my Eclipse managed to pull a version of it already.

When I originally installed Eclipse 3.6.2 and STS at the beginning of the month everything (including debugging) worked flawlessly. So something must have broken during this month.

This is a critical error as I cannot debug any code anymore as this error comes up when you hit your first breakpoint and try to step from there.



 Comments   
Comment by Andrew Eisenberg [ 25/Sep/11 ]

Please use the milestone version of AJDT. It is available here:

http://download.eclipse.org/tools/ajdt/36/milestone

This should fix the abstract method error. Please let me know if this works for you.

Comment by Zahir Toufie [ 25/Sep/11 ]

I can't seem to add the AJDT update url to Eclipse. it says it's a duplicate location, but when I check the available update sites it's not listed so it must be hidden then.

I've checked what the latest AJDT version is and it does look like I have the latest. This is what I currently have installed:

Eclipse AspectJ Development Tools

Version: 2.2.0.e36x-20110908-0800
AspectJ version: 1.6.12.20110908084300

(c) Copyright IBM Corp. and others 2000, 2006. All rights reserved.
Visit http://www.eclipse.org/ajdt

Would it possibly help to downgrade AJDT to this build e36x-20110818-1100 for Eclipse 3.6? I'm also trying to do another re-install, maybe something got out of sync with my updates.

Comment by Andrew Eisenberg [ 25/Sep/11 ]

OK, then make sure that you have installed 2.8.0.M2 of the Grails tooling:

http://dist.springsource.com/milestone/TOOLS/update/2.8.0.M2/e3.6

Is there any reason why you have not upgraded to Eclipse 3.7?

Comment by Zahir Toufie [ 25/Sep/11 ]

OK, here is how one can simulate the problem on Fedora 15 x86_64 with all the latest updates.

1. tar -xzf eclipse-platform-3.6.2-linux-gtk-x86_64.tar.gz
2. Start Eclipse and install all the plugins from the Helios update site except the EclipseRT Target Platform Components.
3. Restart after installing plugins.
4. Create a Java Project and add a new Java class with a main method containing at least 3 lines of code.
5. Set a break point on the first line and debug the test code and check if you can step over the other 2 lines of code.
6. Success and everything works as expected.

7. Following the STS Install Guide for an Update Site here http://download.springsource.com/release/STS/doc/STS-installation_instructions.pdf install the 6 STS feature groups after downloading http://dist.springsource.com/release/TOOLS/composite/e3.6/bookmarks.xml and importing it into the Eclipse Available Sites as per the install guide.
9. Restart after installing the STS plugins.

10. Debug the previously created Java class again.
11. The breakpoint triggers as per usual, but trying to step causes the JDI Event Dispatch error.

Comment by Zahir Toufie [ 25/Sep/11 ]

I'd love to upgrade to Eclipse 3.7.1 except that I can't get the Grails (current production release) plugin installed from the STS Dashboard.

I get this error when I try to install it via the STS Dashboard:

Problems occurred while performing installation: Operation details
Operation details
Cannot complete the install because one or more required items could not be found.
Software currently installed: SpringSource Tool Suite Grails Support 2.7.2.201109131000-RELEASE (com.springsource.sts.grails.feature.group 2.7.2.201109131000-RELEASE)
Missing requirement: JDT Core patch for Groovy-Eclipse plugin 2.5.2.xx-20110921-1600-e37 (org.codehaus.groovy.jdt.patch.feature.group 2.5.2.xx-20110921-1600-e37) requires 'org.eclipse.jdt.feature.group [3.7.0,3.7.1)' but it could not be found
Cannot satisfy dependency:
From: SpringSource Tool Suite Grails Support 2.7.2.201109131000-RELEASE (com.springsource.sts.grails.feature.group 2.7.2.201109131000-RELEASE)
To: org.codehaus.groovy.eclipse.feature.feature.group 2.0.0
Cannot satisfy dependency:
From: Groovy-Eclipse Feature 2.5.2.xx-20110921-1600-e37 (org.codehaus.groovy.eclipse.feature.feature.group 2.5.2.xx-20110921-1600-e37)
To: org.codehaus.groovy.jdt.patch.feature.group [2.5.2.xx-20110921-1600-e37]

Comment by Zahir Toufie [ 25/Sep/11 ]

The 2.8.0.M2 update seems to have fixed the problem on my test Eclipse environment.

Let me try it on my main Eclipse environment and see if I can debug my Grails projects again.

Comment by Andrew Eisenberg [ 25/Sep/11 ]

The reason why you were getting that problem for trying to install on e37 is that you were installing on top of Eclipse 3.7.1. Until Friday, Groovy-Eclipse did not install onto 3.7.1. It looks like you tried to install a Groovy-Eclipse snapshot that was release on Wednesday.

Apologies for all of your installation and compatibility woes. You just happened to try to reinstall during a bad window. Since Groovy-Eclipse provides a patch for JDT core (to integrate groovy into the Java compiler), we cannot release our patch targeting a new release of Eclipse until that release has been made official.

Please let me know if you have any more problems.

Comment by Zahir Toufie [ 25/Sep/11 ]

If I tried to upgrade to 3.7.1 today, will I pick up the usable Groovy-Eclipse release?

i.e. Has the correct Groovy-Eclipse bits for 3.7.1 been released and will STS automatically find it now?

LOL, serves me right for living on the cutting edge, but hey that's a developers life.

Comment by Zahir Toufie [ 26/Sep/11 ]

OK, the 2.8.0.M2 build fixed the JDI Event Dispatch problem on Eclipse 3.6.2.

Thanks for all the help and I'll be sure to try Eclipse 3.7.1 again tonight.

Comment by Zahir Toufie [ 26/Sep/11 ]

STS 2.8.0.M2 fixes this issue





[GRECLIPSE-1207] Groovy editor crash with clean Eclipse 3.7.1 + GRE 20110628 install Created: 23/Sep/11  Updated: 23/Sep/11  Resolved: 23/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Alex Heneveld Assignee: Andy Clement
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

org.osgi.framework.BundleException: Exception in org.codehaus.groovy.eclipse.refactoring.Activator.start() of bundle org.codehaus.groovy.eclipse.refactoring
...
Caused by: java.lang.ClassNotFoundException: org.codehaus.jdt.groovy.integration.LanguageSupport



 Comments   
Comment by Andy Clement [ 23/Sep/11 ]

dup of 1206

Comment by Alex Heneveld [ 23/Sep/11 ]

(submitted prematurely; text below should be in the description)

I was trying to upgrade my old E3.6 + GRE 2.0.2, but it refused to upgrade, so I went for a clean install of latest release Eclipse JEE 3.7.1 and GRE 2.5.1. They don't seem to play nicely however. It all installed fine, but when I went to open a *.groovy file (in the Groovy editor) it started complaining:

java.lang.NoClassDefFoundError: org/codehaus/groovy/eclipse/refactoring/formatter/GroovyIndentationService

Creating a new Groovy project is okay, but creating a new Groovy class gives:

java.lang.ClassCastException: org.eclipse.jdt.internal.core.CompilationUnit cannot be cast to org.codehaus.jdt.groovy.model.GroovyCompilationUnit

Digging around there was also an error thrown in bundle activation (for refactoring):

org.osgi.framework.BundleException: Exception in org.codehaus.groovy.eclipse.refactoring.Activator.start() of bundle org.codehaus.groovy.eclipse.refactoring
...
Caused by: java.lang.ClassNotFoundException: org.codehaus.jdt.groovy.integration.LanguageSupport

Everything is set to use JDK 6 and Groovy 1.8 – no 7's lying about anywhere that I can see, so I don't think this is quite the same as the Java7 issues – although my guess would be they've changed JDT code and the patch no longer is getting activated?

Comment by Andy Clement [ 23/Sep/11 ]

see my comment on 1206 - that groovy-eclipse will not work on eclipse 3.7.1. You need todays dev build (because we patch jdt)





[GRECLIPSE-1206] Groovy editor crash with clean Eclipse 3.7.1 + GRE 20110628 install Created: 23/Sep/11  Updated: 23/Sep/11  Resolved: 23/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Alex Heneveld Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

org.osgi.framework.BundleException: Exception in org.codehaus.groovy.eclipse.refactoring.Activator.start() of bundle org.codehaus.groovy.eclipse.refactoring
...
Caused by: java.lang.ClassNotFoundException: org.codehaus.jdt.groovy.integration.LanguageSupport



 Comments   
Comment by Andy Clement [ 23/Sep/11 ]

groovy-eclipse is not yet compatible with Eclipse 3.7.1 - you need the next dev build ( due in a few mins) for Eclipse 3.7.

Comment by Alex Heneveld [ 23/Sep/11 ]

I can't wait that long! J
Will try it as soon as I see it.

Apologies for the premature duplicate bug submission. Wifi woes.

Comment by Andy Clement [ 23/Sep/11 ]

Fixed. Please install the build from 2 mins ago from this update site:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

Comment by Alex Heneveld [ 23/Sep/11 ]

yep, confirmed fixed. 14m turnaround has to be a record!





[GRECLIPSE-1205] Refactoring of synthetic getters and setters Created: 22/Sep/11  Updated: 14/Oct/11  Resolved: 14/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring, Search
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GRECLIPSE-1010 Ability to rename refactor getter and... Resolved
Number of attachments : 0

 Description   

Related to GRECLIPSE-1204, it should be possible to refactoring synthetic getters and setters:

class First {
  def field
}

getField()
setField(new Object())

Renaming field should also appropriately renamed getField and setField.



 Comments   
Comment by Andrew Eisenberg [ 14/Oct/11 ]

This is now fixed with regression tests.

I added a new rename participant that looks for synthetic getters, setters, and issers.





[GRECLIPSE-1204] Ability to find references to synthetic getter and setter methods using Java/Groovy search Created: 22/Sep/11  Updated: 07/Oct/11  Resolved: 07/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Search
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Given this class:

class First {
  def field
}

getField()
setField(new Object())

Find references on field should find getField and setField. We cannot include them through the SearchEngine since that would affect refactoring. There is the org.eclipse.jdt.ui.queryParticipants extension point, which would probably work in this situation.



 Comments   
Comment by Andrew Eisenberg [ 07/Oct/11 ]

Fixed with regression tests.





[GRECLIPSE-1203] Syntax highlight for slashed strings Created: 21/Sep/11  Updated: 06/Mar/12  Resolved: 09/Feb/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Major
Reporter: Alexey T Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7, 32 bit


Issue Links:
Duplicate
is duplicated by GRECLIPSE-1218 Syntax highlighter is confused by a s... Resolved
is duplicated by GRECLIPSE-1394 Highlighting does not work, if one us... Resolved
Number of attachments : 0

 Description   

Syntax highlight doesn't work for slashed strings with $ at end (for example /^\s+$/) - everything after $/ is highlighted as String



 Comments   
Comment by Andrew Eisenberg [ 21/Sep/11 ]

Groovy 1.8 introduced the Dollar slashy string: http://docs.codehaus.org/display/GROOVY/Groovy+1.8+release+notes#Groovy1.8releasenotes-Dollarslashystrings

Somewhere in your groovy file after the /^s+$/, you must have a /$. Since syntax highlighting of strings is based on regular expressions, I have not yet found an easy way to support both dollar slashy strings and the corner case that you have described.

But, since this is not the first time your problem has come up, it is worth looking into more deeply.

Comment by Croesus [ 06/Jan/12 ]

plz fix very frustrating when working with strings containing unixy directories

Comment by Andrew Eisenberg [ 06/Jan/12 ]

The best fix I can think of would be to have a preference to disable slashy string syntax highlighting. There would be a checkbox somewhere in Preferences -> Groovy -> Editor. Unchecking it would stop this highlighting. Would that be sufficient for you?

Comment by Croesus [ 08/Feb/12 ]

That works fine - thanks

Comment by Andrew Eisenberg [ 09/Feb/12 ]

I'll get this done for 2.6.1.

Comment by Andrew Eisenberg [ 09/Feb/12 ]

There is now an option at the bottom of the Preferences -> Groovy -> Editor page where you can disable dollar slashy strings.





[GRECLIPSE-1202] groovy-eclipse-compiler should have integration tests Created: 20/Sep/11  Updated: 28/Sep/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We should create some integration tests for the groovy-eclipse-compiler to ensure that we don't break things as we fix other things.



 Comments   
Comment by Andrew Eisenberg [ 20/Sep/11 ]

I have 3 simple integration tests that ensure that projects are compiled and tests are run and pass. I need to add in some extra logic to check that the expected number of tests are run.

Comment by Andrew Eisenberg [ 28/Sep/11 ]

Now working.





[GRECLIPSE-1201] maven: empty groovy src directories causes the compiler to ignore java source Created: 19/Sep/11  Updated: 23/Sep/11  Resolved: 23/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Travis Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive no-groovy.zip    
Number of attachments : 1

 Description   

When a project contains empty groovy src folders the plugin will not look for java source and just assume no source exists. This typically happens in a couple of common scenarios that follow the maven convention of split source trees:

1) groovy is only used for testing purposes thus src/main/groovy does not exist or is empty
2) multi-module projects where not all modules use groovy

This is a really annoying issue. The workaround is to include a Dummy.groovy file in every empty groovy source dir - ie you just cannot have empty source dirs



 Comments   
Comment by Andrew Eisenberg [ 20/Sep/11 ]

I tried with this project and cannot reproduce your problem. Does this work for you?

Can you attach a failing project for me to test?

Comment by Andrew Eisenberg [ 20/Sep/11 ]

I just uploaded a 2.5.2-SNAPSHOT to http://nexus.codehaus.org/snapshots/. You may want to try that version. Also, with this version, it is no longer necessary to use build-helper-plugin to add extra source folders. These are discovered automatically if they exist.

Comment by Travis [ 22/Sep/11 ]

Doh! Sorry for wasting your time Andrew. This problem was also fixed in the 2.5.1-1 release.

Comment by Andrew Eisenberg [ 23/Sep/11 ]

Thanks for following up with this. Please let me know if you have any other problems.





[GRECLIPSE-1200] maven: after a successful build, doing a mvn install fails with "The type package-info is already defined" Created: 19/Sep/11  Updated: 20/Sep/11  Resolved: 19/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Critical
Reporter: Travis Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

when building a project that contains package-info.java files doing following command will fail compilation:

mvn install //this will succeed
mvn install //this will fail

the workaround is always to do a mvn clean install

the error you receive relates to the compiler thinking an existing package-info.java already exists.

222. ERROR in C:\projects\kuali\KULRICE-5640\core\api\src\main\java\org\kuali\ri
ce\core\api\util\package-info.java (at line 1)
/*
^
The type package-info is already defined



 Comments   
Comment by Andrew Eisenberg [ 19/Sep/11 ]

Presumably, you have a package-info.java file in the same package in both your src/main/java and src/main/groovy source folders. I tried this on a groovy project and I do see the same error on the command line. It is not there when I stop using the groovy-eclipse-compiler.

However, importing this project into Eclipse, I get "The type package-info is already defined" for all these instances, even when on the command line, this error is not shown.

I'll explore a bit more...

Comment by Travis [ 19/Sep/11 ]

Thanks, Andrew

You can see this error by checking out:

https://test.kuali.org/svn/rice/sandbox/KULRICE-5640

Also, we only have one package-info.java file in our java source tree.

Comment by Andrew Eisenberg [ 19/Sep/11 ]

Now, using the plexus-compiler-eclipse compiler plugin for eclipse, I am still getting the same error as when I use groovy-eclipse.

Note that the problem does not exist when the package-info exists only in src/main/java and src/test/java. Since they are compiled at different phases and have different output directories (but, there is still an error inside of eclipse since everything is compiled at once).

Comment by Travis [ 19/Sep/11 ]

I also ran into this bug in our CI environment

https://bugs.eclipse.org/bugs/show_bug.cgi?id=214948

no clue why it didn't show up locally. Maybe related?

Comment by Andrew Eisenberg [ 19/Sep/11 ]

What??? I must be smoking something. Now, I can't even get a vanilla project with multiple (non-test) source folders to compile if package-infos overlap. I don't know why this was working for me before.

But, it does make some sense. In this situation, which package-info.java file should make it into the output folder? There is fundamentally a conflict here. The package-info from one source folder should apply to the other source folder.

I think that you get away with this for gmaven since the gmaven compiler compiles groovy source separately from java source. But, that begs the question, which package-info.java would you expect to see in the output folder?

I am going to try some more to see if I can get this working again for a vanilla multi-source folder project. And if not, I am starting to think that this "feature" of gmaven is not really a feature...

Comment by Andrew Eisenberg [ 19/Sep/11 ]

Well, let me try your project. I've been hacking away at this without looking for your comments between mine.

Comment by Andrew Eisenberg [ 19/Sep/11 ]

hmmm...with your project. I did:

  1. mvn clean compile
  2. mvn install
  3. mvn install

All commands were successful. What version of maven are you using? I am on 3.0.3.

Comment by Travis [ 19/Sep/11 ]

odd. I'm on Windows 7 running maven 3.0.3.

If you recall we tested out this compiler on the rice project a few months back. Then on was on Windows xp. I don't suppose that makes a difference....

Comment by Andrew Eisenberg [ 19/Sep/11 ]

And I guess you wouldn't see this on the build server since you would never run mvn install twice.

So, when on Windows xp, you had generally the same setup for package-info.java files? There was a change that we recently made so that annotation statements on package declarations are read and stored by the compiler. This was a change to get a piece of gpp working. I wonder if this could be a cause.

What version of g-e-c are you using?

Comment by Travis [ 19/Sep/11 ]

Oh that could be it! Last I tried this I was probably on an older version of g-e-c. I'll try a different version and let you know what I find.

Comment by Travis [ 19/Sep/11 ]

That did it! g-e-c 2.5.1 is broken for me. g-e-c 2.5.1-1 works just fine. So something between those versions is causing the problem.

Comment by Andrew Eisenberg [ 19/Sep/11 ]

Thanks for following up. I am resolving this as fixed, but please re-open if this happens again.

Comment by Travis [ 19/Sep/11 ]

So does that mean it is fixed in trunk? I thought 2.5.1-1 was an older version that 2.5.1....

Comment by Andrew Eisenberg [ 19/Sep/11 ]

No, 2.5.1-1 is the next release after 2.5.1. Is that not considered a greater version in the maven world? I had assumed that the same rules would apply from the OSGi world, where 2.5.1 is less than 2.5.1.1.

I am trying to find the maven documentation for version comparisons, but there is nothing that clearly states the rules. The closest I found is this, but even that is unclear about comparing these kinds of versions.
http://mojo.codehaus.org/versions-maven-plugin/version-rules.html

Well regardless when 2.5.2 comes out I will mark it as 2.5.2-01 just in case I need to put out other releases of the maven support between micro releases of Groovy-Eclipse.

Comment by Travis [ 20/Sep/11 ]

Yup you are right. See here for details: http://docs.codehaus.org/display/MAVEN/Versioning

Comment by Andrew Eisenberg [ 20/Sep/11 ]

Still, I think it is better to be more explicit with version names and the next release will be 2.5.2-01.





[GRECLIPSE-1198] NullPointerException at CompilationUnit for AST transformation Created: 16/Sep/11  Updated: 06/Dec/11  Resolved: 06/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Renato Garcia Assignee: Andy Clement
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Version: Indigo Release
Build id: 20110615-0604
Groovy-Eclipse plugin version: 2.5.2.xx-20110915-1700-e37
Groovy Compiler version: 1.8.2.xx-20110915-1700-e37
Linux rennie 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux


Attachments: File FooBar.groovy     File NewClass.groovy     File NewClassTransformation.groovy    
Testcase included: yes
Number of attachments : 3

 Description   

I get a NPE when I call the code below at an AST transformation.

Please note that this works fine with groovyc cmd line compiler.

def ast = new AstBuilder().buildFromString(CompilePhase.SEMANTIC_ANALYSIS,
		false,
		'''
		package examples
		class NewClass {
		}
		''' )

def newClassNode = ast[1]

GroovyClassLoader cl = sourceUnit.getClassLoader()
		
try{
	CompilationUnit cu = new CompilationUnit(cl)
	cu.addClassNode(newClassNode)
	cu.compile()
}catch(Exception e){
	sourceUnit.addException(e)
}

Exception:

Description Resource Path Location Type
General error during cleanup: java.lang.NullPointerException

java.lang.NullPointerException
at org.codehaus.groovy.control.CompilationUnit$6.call(CompilationUnit.java:818)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1106)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:587)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:565)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:542)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:521)
at org.codehaus.groovy.control.CompilationUnit$compile$0.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
at examples.NewClassTransformation.visit(NewClassTransformation.groovy:42)
at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:159)
at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:225)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1106)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:587)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:565)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:542)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1959)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:820)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:662)
FooBar.groovy /SampleAST/src/examples line 0 Java Problem

I've attached the source code that allows to reproduce the problem. I have two different Eclipse projects, one for the AST and other for the actual use of the AST.



 Comments   
Comment by Andy Clement [ 16/Sep/11 ]

I'm afraid supporting this kind of thing (generating other files as part of compilation) is not very easy. Under eclipse we like to have a nice mapping from sources to their generated artifacts and generating files out of the blue during a build interferes with this. We don't know where they came from, we don't know how to manage them, we can't tidy them up at the right times, on an incremental build of something they refer to, we don't know how to cause them to be recompiled.

You can make it further if you, instead of compiling code in your transform, attach your new classnode for compilation as part of the same SourceUnit for which the transform is running:

Replace all this:

// def newClassNode = ast[1]
//
// GroovyClassLoader cl = sourceUnit.getClassLoader()
//
// try

{ // CompilationUnit cu = new CompilationUnit(cl) // cu.addClassNode(newClassNode) // cu.compile() // }

catch(Exception e)

{ // sourceUnit.addException(e) // }

with this:

sourceUnit.getAST().addClass(ast[1]);

At least we then have a clue which sourceUnit caused the creation of this new ClassNode. But that still hits a groovy-eclipse issue because we will now have a ClassNode for which there is no eclipse binding. I need to think some more on that part of things, I have it working in my workspace but I'm not happy with the change.

Comment by Renato Garcia [ 16/Sep/11 ]

Hi Andy,

Thanks for the prompt response!

I replaced the script that generates a class named NewGeneratedClass instead of NewClass because it was the same name of the annotation which is kind of confusing. Could not edit the description of the issue to fix it though.

I made the changes you mentioned to the code. No more exception but still I don't have the NewGeneratedClass.class created. Is the change that you made that is supposed to make it happen?

I think it is reasonable to expect that this class won't be regenerated unless the source unit is recompiled and the AST transformation is run again.

Also, I have another question, which is one step further. Assuming that I write the DSLD indicating that the class where the AST has been applied has a new field of type NewGeneratedClass, is Eclipse going to recognize the NewGeneratedClass and provide code completion for it?

Comment by Andy Clement [ 17/Sep/11 ]

> No more exception but still I don't have the NewGeneratedClass.class created. Is the change that you made that is supposed to make it happen?

That is what I expected, the exception gone but the class not created. The change I proposed to your script was simply to allow the generated artifact to be associated with a source unit. The class is not coming out because of the missing eclipse binding situation I mentioned in my first comment. As I say, I have a 'hack' that causes the class to come out (i.e. do something dirty when the binding is missing) but I need to think about whether it is a reasonable thing to do as really a missing binding in any other situation (than when an ast transform creates a type like this) is a hard error.

> Also, I have another question, which is one step further. Assuming that I write the DSLD indicating that the class
> where the AST has been applied has a new field of type NewGeneratedClass, is Eclipse going to recognize the NewGeneratedClass and provide code completion for it?

I think you'll be in luck and that will work.

Comment by Andrew Eisenberg [ 06/Dec/11 ]

Any more work to be done on this issue, or can it be resolved?

Comment by Renato Garcia [ 06/Dec/11 ]

I believe this still not working. However, I opened this because we were exploring the possibility of replacing current APT processors we have with AST transformations. We have found alternative approaches for reusing them. So right now we would not use this fix, therefore I'm happy to have this issue closed, maybe with won't fix, and if I or somebody else need this for other purposes in future it can be reopened.

Comment by Andrew Eisenberg [ 06/Dec/11 ]

Thanks for getting back to me on this. Closing as won't fix for now. And please make some noise if you need this working.





[GRECLIPSE-1197] Per-workspace groovy compiler setting Created: 15/Sep/11  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Marco Trevisan Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File eclipseInstalledSoftware.txt    
Issue Links:
dependent
depends upon GRECLIPSE-1328 Groovy Eclipse preventing Eclipse fro... Open
Number of attachments : 1

 Description   

Hi all,

I found out that if I change the groovy compiler setting in a workspace, that change will propagate to all workspaces , so the only way I've found to work on projects requiring different versions of Groovy is to clone and "fork" my Eclipse installations and use the two different versions depending on the workspace I need to open.

Cheers,
Marco



 Comments   
Comment by Andrew Eisenberg [ 15/Sep/11 ]

See http://docs.codehaus.org/display/GROOVY/Compiler+Switching+within+Groovy-Eclipse There are multiple ways of allowing different compiler levels for workspaces that share Eclipse installations. This page will also explain why it is non-trivial to allow multiple compilers within the same workspace.

Comment by Marco Trevisan [ 15/Sep/11 ]

Hi Andrew,

Thanks for the link. I fixed my configuration using the -groovy.compiler.level option (for every launch configuration I have), it allowed me to use a single Eclipse installation.

I also googled before filing the issue, today I must have been blind...

Let me only say it sounds a little strange that the compiler level configuration cannot be saved at workspace scope instead of Eclipse scope. However no problem: there's a workaround.

Cheers,
Marco

Comment by Davide Cavestro [ 16/Sep/11 ]

@Andrew
I see per-project compiler configuration is not feasible (GRECLIPSE-1196) but this issue doesn't ask for allowing multiple compilers within the same workspace but, rather, given a workspace, to get the same behavior as that of the command line switch.
I agree it is not a bug, maybe it should be converted to a RFE, but I think it could be a good enhancement (if ever feasible).

Comment by Andrew Eisenberg [ 16/Sep/11 ]

Is there some reason why the command line switching is not sufficient for you?

The problem that we are facing is that the logic to determine which compiler to use can only be stored in the installation area, not in the workspace area. We can get around this limitation by specifying a compiler level as a command line argument.

Comment by Davide Cavestro [ 16/Sep/11 ]

The command line switching is surely sufficient, but very error prone if you think you have to impose it to several developers that have to work on different projects with different compiler levels: they will surely switch workspace without relaunching eclipse with a different command line switch. It is something like the default encoding... it should be available per-project and per-workspace. That said if it is not feasible we have no choice, but the command line switching is surely not comfortable.

Comment by Marco Trevisan [ 16/Sep/11 ]

In my humble opinion, from a usability standpoint this is without any doubt a bug. If the problem is due to JDT limitations, it may be worth filing an issue to JDT...

That said, I can for sure live without this feature :-D

Cheers,
Marco

Comment by Lari Hotari [ 20/Oct/11 ]

In STS 2.8.0, switching with groovy.compiler.level on command line doesn't work. Error message:

!ENTRY org.eclipse.osgi 4 0 2011-10-20 13:04:06.704
!MESSAGE Startup error
!STACK 1
java.lang.RuntimeException: Exception in org.eclipse.osgi.framework.internal.core.SystemBundleActivator.start() of bundl
e org.eclipse.osgi.
        at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.resume(InternalSystemBundle.java:233)
        at org.eclipse.osgi.framework.internal.core.Framework.launch(Framework.java:655)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:273)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.osgi.framework.internal.core.SystemBundleActivator.start() of bundle org.eclipse.osgi.
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
        at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.resume(InternalSystemBundle.java:225)
        ... 11 more
Caused by: java.lang.IllegalArgumentException: Specified version of Groovy not found. Available versions are: 
        at org.codehaus.groovy.frameworkadapter.CompilerHook.checkVersionFound(CompilerHook.java:121)
        at org.codehaus.groovy.frameworkadapter.CompilerHook.frameworkStart(CompilerHook.java:105)
        at org.eclipse.osgi.baseadaptor.BaseAdaptor.frameworkStart(BaseAdaptor.java:253)
        at org.eclipse.osgi.framework.internal.core.SystemBundleActivator.start(SystemBundleActivator.java:60)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
        ... 13 more

I tried with "-groovy.compiler.level 17".

versions from bundle.info

org.codehaus.groovy,1.7.10.xx-20110929-1800-e37,plugins/org.codehaus.groovy_1.7.10.xx-20110929-1800-e37/,4,false
org.codehaus.groovy,1.8.2.xx-20110929-1800-e37,plugins/org.codehaus.groovy_1.8.2.xx-20110929-1800-e37/,4,false
org.codehaus.groovy.eclipse,2.5.2.xx-20110929-1800-e37,plugins/org.codehaus.groovy.eclipse_2.5.2.xx-20110929-1800-e37.jar,4,false
Comment by Andrew Eisenberg [ 20/Oct/11 ]

Hi Lari,

I cannot reproduce this using a fresh STS 2.8.0. I'll come up with some things you can try to get this working.

Comment by Andrew Eisenberg [ 20/Oct/11 ]

What it seems like to me is that the org.codehaus.groovy bundles are not being found by the osgi framework at startup.

First, try starting STS without the groovy.compiler.level command. Any exceptions And open Preferences -> Groovy -> Compiler. Is the compiler at 1.7.x or 1.8.x?

Then click the button to switch and restart. Does that successfully restart things? Any exceptions?

Lastly, can you try this?

Start STS from the command line, but do not specify a compiler level. Instead use the -console option and start the osgi console.

When the console appears, type this at the prompt:

ss org.codehaus.groovy

What bundles are displayed?

Then, type:

start org.codehaus.groovy

Any exceptions?

Comment by Andrew Eisenberg [ 20/Oct/11 ]

One more thing. I just committed a small change such that Eclipse will still start even if no groovy bundles are found (currently, if no groovy bundles are found, then eclipse will not start this looks like the situation that you are in). This build should be available in about an hour or two. Please upgrade to that dev build and let me know if it works for you.

Comment by Mauro Molinari [ 16/Oct/12 ]

Hi Andrew,
I know it's an annoyance for you, but can we reopen this?
From a user point of view, it's unacceptable that a change in Window | Preferences is not even workspace wide, but SYSTEM wide!!! I can understand it's difficult to find a solution, but current Greclipse behaviour is completely non-standard in the Eclipse environment.
The best would be implementing even GRECLIPSE-1196, but at least having an option per-workspace would be desirable. Having to use command line arguments forces me to have n different shortcuts in my desktop just to launch Eclipse on different workspaces with different command line arguments.

Moreover, the current preferences pages for the Groovy compiler (I'm using Greclipse 2.7.1) talk about "project compiler level" against "workspace compiler level", while the latter is not a "workspace compiler level", but rather a "system (or eclipse installation) compiler level". So it's confusing.

I'm certainly not an Eclipse/OSGi expert, but I really wonder if there isn't a way to implement this using separate classloaders.

Thanks in advance. And no offence... I really appreciate your hard work on Greclipse.

Comment by Andrew Eisenberg [ 16/Oct/12 ]

You can set a per-workspace compiler level if you use command line arguments. In your eclipse.ini or in your startup script add the following:

-groovy.compiler.level
20

Use 18 for groovy 1.8.

Comment by Mauro Molinari [ 16/Oct/12 ]

Hi Andrew,
as I said having to use command line arguments forces me to have n different shortcuts on my desktop just to launch Eclipse on different workspaces with different command line arguments. When you work on dozen projects it becomes a nightmare! This can be a workaround, but not a final solution.
With the number of different Groovy compiler levels increasing (1.7, 1.8, 2.0... and tomorrow?), the need to possibly have different compiler level settings for different workspaces (or even projects) increase.
The current situation does not certainly promote the use of Groovy on enterprise projects, unfortunately.
Moreover, please consider what I said about the confusing text appearing in the preference pages.

Comment by Andrew Eisenberg [ 16/Oct/12 ]

I can understand how 'workspace' compiler level is not exactly appropriate, but neither is 'system' or 'installation' compiler level. 'installation' compiler level implies to me that the compiler level is fixed in the install and cannot be changed without re-installing, which is not true. 'system' compiler level doesn't imply to me that this is the compiler currently being used to compile the sources.

I could go with something more precise, like "active groovy compiler bundle", but that uses OSGi terminology and only makes sense if you think about bundles and plugins, which most users do not.

To me workspace compiler level means that this is the compiler being used by the workspace. Other workspaces may use different compiler levels, which is true. The confusion is that this does not imply that other workspaces need to explicitly specify the compiler level, or else they will use the same as the current workspace.

So, although not perfect terminology, I can't think of anything better. Can you?

Comment by Mauro Molinari [ 16/Oct/12 ]

When you say "workspace compiler level means that this is the compiler being used by the workspace", you imply that another workspace may use another compiler level. So I'm expecting that if you switch the "workspace compiler level", you're switching it for the current workspace. But, surprise... when you start them same Eclipse installation on another workspace, you'll find that the compiler level for that workspace was changed as well.

"Eclipse installation" workspace compiler level sounds better. Or "Eclipse instance" workspace compiler level. Or, at least, leave "workspace compiler level" but clearly specify that if you switch the compiler level from there, the change will take effect also on ALL the other workspaces you'll open with the same Eclipse instance.

Anyway, I'm really sorry you don't even want to consider to reopen this issue

Comment by Andrew Eisenberg [ 16/Oct/12 ]

I'm reopening this issue, as this is something that we would like to do. But given our backlog, we will not be able to work on this soon.

Comment by Mauro Molinari [ 16/Oct/12 ]

Thank you Andrew!

Comment by Mauro Molinari [ 23/Oct/12 ]

Andrew, is the following warning in the Eclipse log (produced at startup) a consequence of how things are currently handled with the use of -groovyCompilerLevel command line switch?

!ENTRY org.eclipse.osgi 2 0 2012-10-23 10:40:20.497
!MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists:
!SUBENTRY 1 org.eclipse.osgi 2 0 2012-10-23 10:40:20.498
!MESSAGE Bundle org.codehaus.groovy_1.7.10.xx-20120921-2000-e42RELEASE [630] was not resolved.
!SUBENTRY 2 org.codehaus.groovy 2 0 2012-10-23 10:40:20.498
!MESSAGE The bundle is disabled: "org.eclipse.pde.ui:Disabled via PDE"
!SUBENTRY 1 org.eclipse.osgi 2 0 2012-10-23 10:40:20.499
!MESSAGE Bundle org.codehaus.groovy_2.0.4.xx-20120921-2000-e42RELEASE [632] was not resolved.
!SUBENTRY 2 org.codehaus.groovy 2 0 2012-10-23 10:40:20.499
!MESSAGE The bundle is disabled: "org.eclipse.pde.ui:Disabled via PDE"
Comment by Andrew Eisenberg [ 23/Oct/12 ]

Possibly, but it is also related to your recent upgrades. You upgraded to a later version of groovy-eclipse and the bundle versions specified above are no longer available.

Are you seeing these on every restart or just once?

Comment by Mauro Molinari [ 23/Oct/12 ]

I'm seeing it on every restart, even if I start Eclipse without the -groovyCompilerLevel. The message is coherent with the actually used Groovy compiler version (i.e.: the bundles mentioned by the warning are those of the other Groovy compiler versions).

Comment by Andrew Eisenberg [ 17/Apr/13 ]

See GRECLIPSE-1328. The fix for that issue will address this one as well.

Comment by Andrew Eisenberg [ 26/Apr/13 ]

We are very close to fixing GRECLIPSE-1328. Resolving this issue as a duplicate. All future comments on this should be added to GRECLIPSE-1328.





[GRECLIPSE-1195] Add a marker for unused imports in Groovy editor Created: 14/Sep/11  Updated: 15/Mar/12  Resolved: 15/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.7.0.Release

Type: New Feature Priority: Minor
Reporter: Mitko Kolev Assignee: Unassigned
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7


Issue Links:
Supercedes
is superceded by GRECLIPSE-1408 Unused imports warning only work for ... Open
Number of attachments : 0

 Description   

Like already discussed in the user mailing lists (http://groovy-eclipse-plugin.42567.n3.nabble.com/Should-the-unused-imports-get-underlined-td3335610.html), it would be nice to have a marker for unused imports.






[GRECLIPSE-1194] Update the JDT Patch for Indigo SR1 (3.7.1) Created: 14/Sep/11  Updated: 12/Dec/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release, 2.5.2.Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Eduardo Garcia Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Indigo SR1 RC1, Snow Leopard 10.6.6, Java 1.6.0_26


Attachments: Text File ex1.txt     Text File ex2.txt    
Number of attachments : 2

 Description   

I've been trying to use GREclipse with no success on an Indigo installation. I've tried with today's (2011/09/14) development snapshot as well as with lastest release version. Also I've tried with 1.7 and 1.8 compilers, always with the same errors.

Anytime I try to create a new class, I get this error:

"Creation of element failed.

org.eclipse.jdt.internal.core.CompilationUnit cannot be cast to org.codehaus.jdt.groovy.model.GroovyCompilationUnit".

I've attached the full exception on eclipse log (ex1.txt)

Anyway, the class is created. But anytime I double click on it, I get the following response (similar to bug https://jira.codehaus.org/browse/GRECLIPSE-1177, but not the same)

"An error has occurred. See error log for more details.
org/codehaus/groovy/eclipse/refactoring/formatter/GroovyIndentationService"

When I check the log, I see the exception I've attached on ex2.txt.

Hope this helps!



 Comments   
Comment by Andrew Eisenberg [ 14/Sep/11 ]

It looks like the JDT patch has not been installed properly. There are several reasons for this. The most likely possibility is that you have installed Eclipse into a read-only location. In order for Eclipse to install Groovy-Eclipse's JDT patch, the install location must be writable by the current user.

If this isn't the cause, then there are some other possibilities that that might be causing this.

Comment by Eduardo Garcia [ 15/Sep/11 ]

I see the following on my list of installed plugins:

Groovy Compiler 1.8 Feature 2.5.2.xx-20110912-2200-e37 org.codehaus.groovy18.feature.feature.group Codehaus.org
Groovy-Eclipse Feature 2.5.2.xx-20110912-2200-e37 org.codehaus.groovy.eclipse.feature.feature.group Codehaus.org
Groovy Compiler 1.7.10 Feature 2.5.2.xx-20110912-2200-e37 org.codehaus.groovy17.feature.feature.group Codehaus.org
Groovy-Eclipse Headless Feature 2.5.2.xx-20110912-2200-e37 org.codehaus.groovy.headless.feature.feature.group Codehaus.org
JDT Core patch for Groovy-Eclipse plugin 2.5.2.xx-20110912-2200-e37 org.codehaus.groovy.jdt.patch.feature.group Codehaus.orghaus.org

The "JDT Core patch" icon has a red plus sign, don't know if that means it's not installed (it also appeared in the Install new software page). I've tried with Helios and there is no red plus sign in the icon.

Comment by Andrew Eisenberg [ 15/Sep/11 ]

What is the filesystem location of your installation? What operating system/version are you using? Do you have write access in that location?

Installing Groovy-Eclipse into C:\Program Files on Windows 7 does not work.

Comment by Eduardo Garcia [ 16/Sep/11 ]

Sorry for the late comment. I'm not getting any email every time you reply :S

As I stated in the Environment up there, I'm using Indigo SR1 RC1, Snow Leopard 10.6.6, Java 1.6.0_26. Location is totally writable. I don't know if in Mac spaces are a problem, but anyway, no spaces in the full path: /Users/MyUser/Development/eclipse-indigo-sr1-rc1. Lot's of plugins have been installed without problem.

I've also installed AspectJ compiler, and Scala Plugin, don't know if those two can cause any problem (but I have a working Helios installation with AspectJ compiler installed alongside, and it's working fine)

Comment by Andrew Eisenberg [ 16/Sep/11 ]

Ahhh...I missed that the first time. Groovy-Eclipse is not yet compatible with 3.7.1 (it is not officially out yet and we have to rework our patch to be based off of 3.7.1 instead of 3.7.0). We will be making the new patch available in the next week or so.

Comment by Andrew Eisenberg [ 16/Sep/11 ]

I updated the issue's title to more appropriately reflect the task that we need to accomplish.

Comment by Eduardo Garcia [ 16/Sep/11 ]

Ahh... I see, sorry for the confusion. I'll be making noise again in a few weeks, then .

Comment by Andrew Eisenberg [ 16/Sep/11 ]

I or someone else will comment on this issue when the patch is available for 3.7.1.

Comment by Andrew Eisenberg [ 28/Sep/11 ]

The patch for 3.7.1 is now available.

Comment by Simon McClenahan [ 09/Dec/11 ]

I'm getting the same error when I try top open a groovy file.

eclipse.buildId=M20110909-1335
java.version=1.7.0_147-icedtea
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product

Groovy-Eclipse Feature 2.6.0.xx-20111207-0900-e36 org.codehaus.groovy.eclipse.feature.feature.group Codehaus.org
Groovy Compiler 1.7.10 Feature 2.6.0.xx-20111207-0900-e36 org.codehaus.groovy17.feature.feature.group Codehaus.org
Groovy-Eclipse Headless Feature 2.6.0.xx-20111207-0900-e36 org.codehaus.groovy.headless.feature.feature.group Codehaus.org
JDT Core patch for Groovy-Eclipse plugin 2.6.0.xx-20111207-0900-e36 org.codehaus.groovy.jdt.patch.feature.group Codehaus.org

Comment by Andrew Eisenberg [ 09/Dec/11 ]

You are using Eclipse 3.6. Eclipse 3.6 does not support Java 7. You must upgrade to Eclipse 3.7.

Comment by Simon McClenahan [ 12/Dec/11 ]

I am using 3.7/Indigo. I don't know why the features reference e36, maybe because I'm using Groovy 1.7?

Anyway the problem has just now seemed to be resolved when I did an Eclipse update, now referencing e37.

Groovy-Eclipse Feature 2.6.0.xx-20111211-1800-e37 org.codehaus.groovy.eclipse.feature.feature.group Codehaus.org
Groovy Compiler 1.7.10 Feature 2.6.0.xx-20111211-1800-e37 org.codehaus.groovy17.feature.feature.group Codehaus.org
Groovy-Eclipse Headless Feature 2.6.0.xx-20111211-1800-e37 org.codehaus.groovy.headless.feature.feature.group Codehaus.org
JDT Core patch for Groovy-Eclipse plugin 2.6.0.xx-20111211-1800-e37 org.codehaus.groovy.jdt.patch.feature.group Codehaus.org
Eclipse Java Development Tools 3.7.1.r371_v20110810-0800-7z8gFcoFMLfTabvKsR5Qm9rBGEBK org.eclipse.jdt.feature.group Eclipse.org





[GRECLIPSE-1193] Groovy++ 0.9.0 doesn't work with Groovy 1.8.2 with GRECLIPSE 2.5.1 on Eclipse 3.7 Created: 10/Sep/11  Updated: 13/Sep/11  Resolved: 13/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution, Testing, Running, Debugging
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Wish Priority: Major
Reporter: Lawrence Lewis Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 SP1 32-bit, Java 1.7


Attachments: Zip Archive FibBenchmark.zip    
Testcase included: yes
Number of attachments : 1

 Description   

Using the Groovy+: groovypp-0.9.0_1.8.2 distribution for Groovy, installing GRECLIPSE 2.5.1 via eclipse update site for 3.7, and all default settings, groovy+ Fib benchmark clearly shows it is not using groovy++. When the identical file is run in groovyConsole, it is 10x faster. Additional tests like the following work fine in groovyConsole, but fail at runtime in eclipse:

package mypackage

class Greet {
static main(args)

{ def hh = "ABC".lower() println hh }

static String lower(String self)

{ return self.toLowerCase() }

}

Exception in thread "main" groovy.lang.MissingMethodException: No signature of method: java.lang.String.lower() is applicable for argument types: () values: []



 Comments   
Comment by Andrew Eisenberg [ 10/Sep/11 ]

You say that you are using Groovy 1.8.2 and Groovy-Eclipse 2.5.1 release. However, 2.5.1 only ships with 1.8.1. Only the dev builds of 2.5.2 have 1.8.2. Just trying to clarify versions to make this problem easier to track.

Comment by Andy Clement [ 10/Sep/11 ]

Oh i see you raised a new issue. ignore my comment on the other bug. It would still be helpful for you to attach a project here so I can confirm your configuration, just zip it up and attach it. As Andrew says, you need to confirm what versions you are using - if you are using a groovy++ that is targetting 1.8.2 groovy then you need to be on a groovy-eclipse dev build, not the 2.5.1 release.

Comment by Andy Clement [ 10/Sep/11 ]

Ok, tried it out, works fine for me. Groovy-Eclipse dev build with groovy++ 0.9.0 for 1.8.2

Fib benchmark:

Without @Typed:
Groovy(static ternary): 17256ms
Groovy(static if): 17594ms
Groovy(instance ternary): 17870ms
Groovy(instance if): 16247ms

With @Typed:
Groovy(static ternary): 640ms
Groovy(static if): 569ms
Groovy(instance ternary): 556ms
Groovy(instance if): 576ms

I'm not sure what you are saying about the code you have included above. It doesn't work me in eclipse, it doesn't work for me in groovy console... how is it related to groovy++ ? In groovy console on attempting to run this:
===
package mypackage

class Greet {
static main(args)

{ def hh = "ABC".lower() println hh }

static String lower(String self)

{ return self.toLowerCase() }

}
===
I get:

Apparent variable 'hh' was found in a static scope but doesn't refer to a local variable, static field or class. Possible causes:
You attempted to reference a variable in the binding or an instance variable from a static context.
You misspelled a classname or statically imported field. Please check the spelling.
You attempted to use a method 'hh' but left out brackets in a place not allowed by the grammar.
at line: 4, column: 52

(that is groovy 1.8.2)

Comment by Lawrence Lewis [ 10/Sep/11 ]

Attached my fib eclipse project above.
lower() is an extension/category method allowed by groovy++
Sorry...the code I sent lost a carriage return. Here's the proper code along with the stand alone groovyConsole output:

@Typed package mypackage

class Greet {
static main(args) {
def hh = "ABC".lower()
println hh
}

static String lower(String self) { return self.toLowerCase() }
}

groovy> @Typed package mypackage 
groovy> class Greet { 
groovy> static main(args) { 
groovy> def hh = "ABC".lower() 
groovy> println hh 
groovy> } 
groovy> static String lower(String self) { return self.toLowerCase() } 
groovy> } 
 
abc
Comment by Lawrence Lewis [ 10/Sep/11 ]

hm...the markup keeps losing the carriage return after "ABC".lower()

Comment by Andy Clement [ 10/Sep/11 ]

I unzipped the attached project, but it contains no reference to a groovy++ library, you need to have that.

Groovy-Eclipse is failing to tell you that @Typed cannot be resolved (a greclipse bug). If you annotate the class declaration you will see @Typed cannot be resolved. If you add a version of groovy++ to the project classpath then @Typed will resolve and your code will be g++ compiled. I simply grabbed the 0.9.0 jar and put it on my project classpath.

Comment by Andy Clement [ 10/Sep/11 ]

I imagine the same thing is going on with your other code snippet. (1) you annotated the package decl, which greclipse isn't liking (2) you didn't include a version of groovy++ on the project classpath.

I'll let this bug cover the annotated package decl issue.

Comment by Lawrence Lewis [ 10/Sep/11 ]

ah...thanks. I also see I'm actually using the 1.7 compiler, not 1.8...have to do the compiler switch thing

Comment by Andy Clement [ 10/Sep/11 ]

fix committed for package annotations.

Comment by Andy Clement [ 13/Sep/11 ]

fix available in dev builds.





[parser] Better parser recovery (GRECLIPSE-468)

[GRECLIPSE-1192] Parser recovery for extra comment at end of line Created: 08/Sep/11  Updated: 01/Nov/11  Resolved: 01/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.0.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following two code snippets break the parser because of the trailing comma. This is one is important since we want to start handling content assist for named arguments (GRECLIPSE-1120).

nuthin s,
def x = {
     nuthin s, 
}


 Comments   
Comment by Andy Clement [ 01/Nov/11 ]

fixed (in 1.8)





[GRECLIPSE-1191] Groovy-Eclipse-compiler should automatically recognize src/main/groovy and src/test/groovy as source folders Created: 08/Sep/11  Updated: 18/Nov/11  Resolved: 20/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The groovy-eclipse-compiler should automatically recognize src/main/groovy and src/test/groovy as source folders if they exist. There shouldn't be any need for the build-helper-plugin to add these as source folders instead.



 Comments   
Comment by Andrew Eisenberg [ 20/Sep/11 ]

Now working locally. I will create a snapshot release soon.

Comment by Andrew Eisenberg [ 20/Sep/11 ]

Snapshot of 2.5.2-SNAPSHOT now available from codehaus snapshots repository here:
http://nexus.codehaus.org/snapshots/

Comment by Oliver Blaha [ 18/Nov/11 ]

Does not always work. See GRECLIPSE-1257.





[GRECLIPSE-1190] Add declaringType and hasParameter pointcuts Created: 06/Sep/11  Updated: 06/Sep/11  Resolved: 06/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We should be able to handle expressions like this:

enclosingMethod(name("foo") & declaringType("test.Main") & hasParameter("arg")).accept {
  property name:"arg", type:"test.Main"
}

This will match whenever inside a method named foo in a type named foo.Main with an argument named arg.

I am a little unsure about hasParameter. We already have hasArgument, but that is intended for method call sites instead of the declarations. Perhaps we should use hasArgument here as well.



 Comments   
Comment by Andrew Eisenberg [ 06/Sep/11 ]

We should also be able to handle variants like this:

enclosingMethod(name("foo") & declaringType("test.Main") & hasParameter(name("arg")) & type("java.lang.String")).accept {
  property name:"arg", type:"test.Main"
}

Here the name and type of the parameter is specified.

Comment by Andrew Eisenberg [ 06/Sep/11 ]

In order to avoid confusion, I have decided to overload the hasArgument pointcut instead of introducing a new hasParameter pointcut.

So, the above dsld snippet will use hasArgument instead of hasParameter. All else is implemented as described.





[GRECLIPSE-1188] Better handling of 'The Spock compiler plugin could not run because Spock 0.5.0-groovy-1.8 is not compatible with Groovy 1.7.10.' Created: 01/Sep/11  Updated: 02/Nov/11  Resolved: 02/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Andy Clement
Resolution: Fixed  
Labels: wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When I get the error it crashes the 'build' in Eclipse and returns an error like:

An internal error occurred during: "Building workspace".
The Spock compiler plugin could not run because Spock 0.5.0-groovy-1.8 is not compatible with Groovy 1.7.10.'

Why is this an 'internal error'? It is a problem with the user's project setup and workspace conf.

Also I think this internal error crashes the build which tends to leave the workspace UI etc. in a confused state leading to other weird problems (such as exceptions being thrown from some UI processes).

It would be nicer when this error rather than 'crashing' the Eclipse build would instead result in some kind of an error marker in the Problems view... it may also help in identifying a project or resource involved in causing the error. (Maybe a specific project / resource that has spock tests in it in this case).



 Comments   
Comment by Andy Clement [ 02/Nov/11 ]

this is what happens when you let random user code run as part of compilation...

Fixed. We now catch the guff that might be coming out of transform instance construction and record an appropriate error.





[GRECLIPSE-1187] Mechanism to test DSLDs Created: 01/Sep/11  Updated: 29/Sep/11  Resolved: 29/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support, Testing, Running, Debugging
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, there is no easy way to create automated tests for DSLD scripts. I've been playing around with some ideas and here is what I have implemented so far:

  • A way to invoke the inferencing engine for an entire project
  • All unknown references are marked
  • Also, there is special syntax for denoting a type check. If the type check fails, then this location is also marked.
  • There is a way to invoke the inferencing engine from the command line (through an Eclipse Application extension point).
  • All marked locations are sent to sysout.

The special syntax for a type check is something like this:

assert true || someExpr == "java.util.List<java.lang.Integer>"

someExpr is any expression whose type should be checked. The RHS of the == is a string representation of the expected type. The true is required so that if this assertion statement is executed at runtime, it will never fail. Since the static checker looks at the AST, the format above is strict. Assertion statements that do conform to the syntax above will not be checked.

This can be executed from the command line like so (where myProject is the name of a project already in the workspace):

eclipse -application org.codehaus.groovy.eclipse.dsl.staticCheck myProject

What I have now works, but is a little crude. Here are the current problems:

  1. Too many false positives. There needs to be a way to mark certain expressions as ignored even though they may have unknown types.
  2. It would be nice to be able to specify extra dsld files on the command line to apply to the project.
  3. It would be nice if the project was not necessarily already installed in the workspace (eg- instead of a project name, a full path could be given). The project would be imported, checked and then removed from the workspace on shutdown.
  4. It would be even better if the files checked didn't have to be in a project (as long as they were in a source folder or something).
  5. Lastly, it would be good to move away from the awkward assertion statement syntax and move towards using comments to direct the type checking.


 Comments   
Comment by Andrew Eisenberg [ 01/Sep/11 ]

Somehow, this issue was created twice. Closing this one. Instead, go to GRECLIPSE-1186.





[GRECLIPSE-1186] Mechanism to test DSLDs Created: 01/Sep/11  Updated: 02/Sep/11  Resolved: 02/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support, Testing, Running, Debugging
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, there is no easy way to create automated tests for DSLD scripts. I've been playing around with some ideas and here is what I have implemented so far:

  • A way to invoke the inferencing engine for an entire project
  • All unknown references are marked
  • Also, there is special syntax for denoting a type check. If the type check fails, then this location is also marked.
  • There is a way to invoke the inferencing engine from the command line (through an Eclipse Application extension point).
  • All marked locations are sent to sysout.

The special syntax for a type check is something like this:

assert true || someExpr == "java.util.List<java.lang.Integer>"

someExpr is any expression whose type should be checked. The RHS of the == is a string representation of the expected type. The true is required so that if this assertion statement is executed at runtime, it will never fail. Since the static checker looks at the AST, the format above is strict. Assertion statements that do conform to the syntax above will not be checked.

This can be executed from the command line like so (where myProject is the name of a project already in the workspace):

eclipse -application org.codehaus.groovy.eclipse.dsl.staticCheck myProject

What I have now works, but is a little crude. Here are the current problems:

  1. Too many false positives. There needs to be a way to mark certain expressions as ignored even though they may have unknown types.
  2. It would be nice to be able to specify extra dsld files on the command line to apply to the project.
  3. It would be nice if the project was not necessarily already installed in the workspace (eg- instead of a project name, a full path could be given). The project would be imported, checked and then removed from the workspace on shutdown.
  4. It would be even better if the files checked didn't have to be in a project (as long as they were in a source folder or something).
  5. Lastly, it would be good to move away from the awkward assertion statement syntax and move towards using comments to direct the type checking.


 Comments   
Comment by Andrew Eisenberg [ 02/Sep/11 ]

I have committed some more functionality. Now, it is possible to add exclusion/inclusion filters, specify that only type assertions should be checked (unknown expressions should be ignored), and it is possible to add extra DSLDs on the command line.

Also, I have changed how to specify type assertions. Type assertions are now specified in a comment next to the expression to be asserted. Eg:

def name = ""
name // TYPE:java.lang.String

This is a type assertion that name is of type string. As before, it is possible to specify parameterized types.

I am resolving this as fixed, but once I get some more feedback, I will make some changes.





[GRECLIPSE-1185] groovy class with an inner class does not compile Created: 31/Aug/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Szczepan Faber Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I think I may have came across a bug. Below sample does not compile in eclipse 3.7 + groovy plugin 2.5.1 + groovy 1.7. However, it does compile outside eclipse.

class WithInnerClass {
		
	interface InnerInterface {
		void foo()
	}

	private final InnerInterface foo = new InnerInterface() {
		void foo() {
			
		}
	}
}

The problem has an easy workaround - make the inner class a top-level one. Hopefully, you'll find this report useful

Thanks a bunch for the plugin!!!
Cheers!



 Comments   
Comment by Andrew Eisenberg [ 31/Aug/11 ]

Inside of Eclipse, I get a compile error when using the 1.7 compiler, but not when using the 1.8 compiler. I get the same behavior on the command line. Are you using groovy 1.8 on the command line, but 1.7 inside of Eclipse by any chance?

Comment by Szczepan Faber [ 31/Aug/11 ]

I'm pretty sure that we use 1.7.10. One thing I should mention earlier that it is a mixed java+groovy project.

Comment by Andrew Eisenberg [ 31/Aug/11 ]

OK. Interesting. Looking a bit more closely, it seems that I was using 1.7.2 on the command line, and when I upgraded to 1.7.10, I was able to successfully compile. But, I am still getting the compile error in Eclipse when using 1.7.10.

I'll look into this since there should not be any differences in the syntax accepted inside of Eclipse and that accepted outside (we do patch the groovy compiler, but that should not have an effect on what can be compiled).

Comment by Szczepan Faber [ 31/Aug/11 ]

Ok. Thanks for info!

Comment by Andrew Eisenberg [ 31/Aug/11 ]

I looked at the original code for 1.7.10 as well as the code for our patched 1.7.10. There is a discrepancy in AntlrParserPlugin. The unpatched version can handle inner-interfaces, but the patched version cannot. It looks like this was missed during the latest upgrade of the patch.

Specifically, it looks like the innerInterfaceDef method exists in the unpatched version, but not the patched. Also, the objectBlock method has a case statement in its switch body for interfaces in the unpatched version, but not the patched.

I'm assigning this bug to Andy since he is the one who created the groovy compiler patch. The build server is currently out of service, so we can't get a fix out to you today, but we will once the server is running again.

Comment by Szczepan Faber [ 01/Sep/11 ]

no worries, it's not critical. Thanks for info!

Comment by Andy Clement [ 15/Oct/11 ]

dont think there is anything further I need to do, and the fix was in 2.5.2





[GRECLIPSE-1184] ResourceException: Linked resources are not supported by this application Created: 26/Aug/11  Updated: 02/Sep/11  Resolved: 02/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Aaron Digulla Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to GRECLIPSE-1189 Warn users when Linked resources are ... Open
Number of attachments : 0

 Description   

Since the introduction of "DSLD" (whatever that might be), I see this stack trace at startup:

!MESSAGE Error while creating a link for external folder :/home/adigulla/.groovy/greclipse/global_dsld_support
org.eclipse.core.internal.resources.ResourceException: Linked resources are not supported by this application.
        at org.eclipse.core.internal.resources.Resource.assertLinkRequirements(Resource.java:160)

The folder exists.



 Comments   
Comment by Aaron Digulla [ 26/Aug/11 ]

Here is the full stack trace:

!ENTRY org.eclipse.jdt.core 4 4 2011-08-26 10:19:20.587
!MESSAGE Error while creating a link for external folder :/home/adigulla/.groovy/greclipse/global_dsld_support
!STACK 1
org.eclipse.core.internal.resources.ResourceException: Linked resources are not supported by this application.
        at org.eclipse.core.internal.resources.Resource.assertLinkRequirements(Resource.java:160)
        at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:649)
        at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:623)
        at org.eclipse.jdt.internal.core.ExternalFoldersManager.createLinkFolder(ExternalFoldersManager.java:153)
        at org.eclipse.jdt.internal.core.ExternalFoldersManager.createPendingFolders(ExternalFoldersManager.java:173)
        at org.eclipse.jdt.core.JavaCore.initializeAfterLoad(JavaCore.java:3601)
        at org.eclipse.jdt.internal.ui.InitializeAfterLoadJob$RealJob.run(InitializeAfterLoadJob.java:36)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
!SUBENTRY 1 org.eclipse.core.resources 4 77 2011-08-26 10:19:20.587
!MESSAGE Linked resources are not supported by this application.

!ENTRY org.codehaus.groovy.eclipse.dsl 4 0 2011-08-26 10:19:21.576
!MESSAGE /home/adigulla/.groovy/greclipse/global_dsld_support does not exist
!STACK 1
Java Model Exception: Java Model Status [/home/adigulla/.groovy/greclipse/global_dsld_support does not exist]
        at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:505)
        at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:246)
        at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:518)
        at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
        at org.eclipse.jdt.internal.core.Openable.open(Openable.java:432)
        at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findDSLDsInLibraries(RefreshDSLDJob.java:111)
        at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findFiles(RefreshDSLDJob.java:84)
        at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.refreshProject(RefreshDSLDJob.java:271)
        at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:219)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
!SUBENTRY 1 org.eclipse.jdt.core 4 969 2011-08-26 10:19:21.577
!MESSAGE /home/adigulla/.groovy/greclipse/global_dsld_support does not exist

!ENTRY org.codehaus.groovy.eclipse.dsl 4 0 2011-08-26 10:19:21.577
!MESSAGE /home/adigulla/.groovy/greclipse/global_dsld_support does not exist
!STACK 1
Java Model Exception: Java Model Status [/home/adigulla/.groovy/greclipse/global_dsld_support does not exist]
        at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:505)
        at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:246)
        at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:504)
        at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:240)
        at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:518)
        at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
        at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
        at org.eclipse.jdt.internal.core.PackageFragment.getNonJavaResources(PackageFragment.java:323)
        at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findDSLDsInLibraries(RefreshDSLDJob.java:137)
        at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findFiles(RefreshDSLDJob.java:84)
        at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.refreshProject(RefreshDSLDJob.java:271)
        at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:219)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
!SUBENTRY 1 org.eclipse.jdt.core 4 969 2011-08-26 10:19:21.578
!MESSAGE /home/adigulla/.groovy/greclipse/global_dsld_support does not exist
Comment by Aaron Digulla [ 26/Aug/11 ]

I'm using Eclipse 3.7.0 (Indigo) on Linux (Ubuntu 10.10) with Java 1.6.0.26

Comment by Andrew Eisenberg [ 01/Sep/11 ]

Apologies for taking so long to reply. I have just returned from vacation.

Can you go to Preferences -> General -> Workspace -> Linked Resources? Make sure that "Enable linked resources" is checked. This should be checked by default, but I've seen some cases where this was disabled on Linux. Please let me know if this helps.

This exception only affects DSL support. It does not affect compilation or the execution of your groovy code.

Comment by Aaron Digulla [ 02/Sep/11 ]

Yes, that works.

Can you check the value of this preferences setting? If so, please display a dialog with instructions how to fix it when the setting is "wrong".

Comment by Andrew Eisenberg [ 02/Sep/11 ]

Fixed. Well, actually, things are working as designed. But, we could make this problem and solution more explicit. I'll raise a new bug for that.





[GRECLIPSE-1182] As a user, I would like the ability to suppress certain DGM references from content assist Created: 19/Aug/11  Updated: 18/Jan/12  Resolved: 01/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.1.M1

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As described in https://issuetracker.springsource.com/browse/STS-1987, certain DGM references in content assist are not used very often and can clutter the content assist operations.

There should be a preference option to hide little-used DGM references from content assist.

A grander version of this feature would allow users to select their own DGM methods to filter, but a first go at this would be to hard code a list.



 Comments   
Comment by Andrew Eisenberg [ 26/Oct/11 ]

Let's get this done for 2.6.0.

Comment by Andrew Eisenberg [ 01/Dec/11 ]

Implementation appears to be working. Creating regression tests.

Comment by Andrew Eisenberg [ 01/Dec/11 ]

Fix has been committed with regression tests.





[GRECLIPSE-1181] out of space in CodeCache for adapters Created: 19/Aug/11  Updated: 31/Aug/11  Resolved: 31/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Robert Winch Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
      • Date: Friday, June 3, 2011 3:06:54 PM Central Daylight Time
      • Platform Details:
      • System properties:
        com.atlassian.connector.eclipse.branding.ui.isOnlyJiraInstalled=true
        eclipse.application=org.eclipse.ui.ide.workbench
        eclipse.buildId=2.6.1.201105041000-RELEASE
        eclipse.commands=-os
        linux
        -ws
        gtk
        -arch
        x86
        -showsplash
        -launcher
        /home/rwinch/downloads/springsource/sts-2.6.0.SR1/STS
        -name
        STS
        --launcher.library
        /home/rwinch/downloads/springsource/sts-2.6.0.SR1//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.1.2.R36x_v20101019_1345/eclipse_1310.so
        -startup
        /home/rwinch/downloads/springsource/sts-2.6.0.SR1//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
        -product
        com.springsource.sts.ide
        -vm
        /usr/lib/jvm/jdk1.6.0_24/jre/bin/../lib/i386/client/libjvm.so
        eclipse.home.location=file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/
        eclipse.launcher=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/STS
        eclipse.launcher.name=STS
        eclipse.p2.data.area=@config.dir/../p2/
        eclipse.p2.profile=com.springsource.sts.ide
        eclipse.product=com.springsource.sts.ide
        eclipse.startTime=1307107267021
        eclipse.vm=/usr/lib/jvm/jdk1.6.0_24/jre/bin/../lib/i386/client/libjvm.so
        eclipse.vmargs=-Dosgi.requiredJavaVersion=1.5
        -Xms40m
        -Xmx768m
        -XX:MaxPermSize=256m
        -Djava.class.path=/home/rwinch/downloads/springsource/sts-2.6.0.SR1//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
        equinox.use.ds=true
        file.encoding=UTF-8
        file.encoding.pkg=sun.io
        file.separator=/
        guice.disable.misplaced.annotation.check=true
        java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
        java.awt.printerjob=sun.print.PSPrinterJob
        java.class.path=/home/rwinch/downloads/springsource/sts-2.6.0.SR1//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
        java.class.version=50.0
        java.endorsed.dirs=/usr/lib/jvm/jdk1.6.0_24/jre/lib/endorsed
        java.ext.dirs=/usr/lib/jvm/jdk1.6.0_24/jre/lib/ext:/usr/java/packages/lib/ext
        java.home=/usr/lib/jvm/jdk1.6.0_24/jre
        java.io.tmpdir=/tmp
        java.library.path=/usr/lib/jvm/jdk1.6.0_24/jre/lib/i386/client:/usr/lib/jvm/jdk1.6.0_24/jre/lib/i386::/usr/java/packages/lib/i386:/lib:/usr/lib
        java.protocol.handler.pkgs=org.apache.axis.transport|
        java.runtime.name=Java(TM) SE Runtime Environment
        java.runtime.version=1.6.0_24-b07
        java.specification.name=Java Platform API Specification
        java.specification.vendor=Sun Microsystems Inc.
        java.specification.version=1.6
        java.vendor=Sun Microsystems Inc.
        java.vendor.url=http://java.sun.com/
        java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi
        java.version=1.6.0_24
        java.vm.info=mixed mode, sharing
        java.vm.name=Java HotSpot(TM) Client VM
        java.vm.specification.name=Java Virtual Machine Specification
        java.vm.specification.vendor=Sun Microsystems Inc.
        java.vm.specification.version=1.0
        java.vm.vendor=Sun Microsystems Inc.
        java.vm.version=19.1-b02
        line.separator=

org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
org.eclipse.debug.ui.breakpoints.toggleFactoriesUsed=false
org.eclipse.equinox.launcher.splash.location=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/com.springsource.sts_2.6.1.201105041000-RELEASE/splash.bmp
org.eclipse.equinox.simpleconfigurator.configUrl=file:org.eclipse.equinox.simpleconfigurator/bundles.info
org.eclipse.jdt.debug.ui.debuggerActive=false
org.eclipse.jdt.debug.ui.instanceof.IJavaStackFrame=false
org.eclipse.jdt.debug.ui.supportsForceReturn=false
org.eclipse.jdt.debug.ui.supportsInstanceRetrieval=false
org.eclipse.update.reconcile=false
org.osgi.framework.executionenvironment=OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,JRE-1.1,J2SE-1.2,J2SE-1.3,J2SE-1.4,J2SE-1.5,JavaSE-1.6
org.osgi.framework.language=en
org.osgi.framework.os.name=Linux
org.osgi.framework.os.version=2.6.38
org.osgi.framework.processor=x86
org.osgi.framework.system.packages=javax.accessibility,javax.activation,javax.activity,javax.annotation,javax.annotation.processing,javax.crypto,javax.crypto.interfaces,javax.crypto.spec,javax.imageio,javax.imageio.event,javax.imageio.metadata,javax.imageio.plugins.bmp,javax.imageio.plugins.jpeg,javax.imageio.spi,javax.imageio.stream,javax.jws,javax.jws.soap,javax.lang.model,javax.lang.model.element,javax.lang.model.type,javax.lang.model.util,javax.management,javax.management.loading,javax.management.modelmbean,javax.management.monitor,javax.management.openmbean,javax.management.relation,javax.management.remote,javax.management.remote.rmi,javax.management.timer,javax.naming,javax.naming.directory,javax.naming.event,javax.naming.ldap,javax.naming.spi,javax.net,javax.net.ssl,javax.print,javax.print.attribute,javax.print.attribute.standard,javax.print.event,javax.rmi,javax.rmi.CORBA,javax.rmi.ssl,javax.script,javax.security.auth,javax.security.auth.callback,javax.security.auth.kerberos,javax.security.auth.login,javax.security.auth.spi,javax.security.auth.x500,javax.security.cert,javax.security.sasl,javax.sound.midi,javax.sound.midi.spi,javax.sound.sampled,javax.sound.sampled.spi,javax.sql,javax.sql.rowset,javax.sql.rowset.serial,javax.sql.rowset.spi,javax.swing,javax.swing.border,javax.swing.colorchooser,javax.swing.event,javax.swing.filechooser,javax.swing.plaf,javax.swing.plaf.basic,javax.swing.plaf.metal,javax.swing.plaf.multi,javax.swing.plaf.synth,javax.swing.table,javax.swing.text,javax.swing.text.html,javax.swing.text.html.parser,javax.swing.text.rtf,javax.swing.tree,javax.swing.undo,javax.tools,javax.transaction,javax.transaction.xa,javax.xml,javax.xml.bind,javax.xml.bind.annotation,javax.xml.bind.annotation.adapters,javax.xml.bind.attachment,javax.xml.bind.helpers,javax.xml.bind.util,javax.xml.crypto,javax.xml.crypto.dom,javax.xml.crypto.dsig,javax.xml.crypto.dsig.dom,javax.xml.crypto.dsig.keyinfo,javax.xml.crypto.dsig.spec,javax.xml.datatype,javax.xml.namespace,javax.xml.parsers,javax.xml.soap,javax.xml.stream,javax.xml.stream.events,javax.xml.stream.util,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.sax,javax.xml.transform.stax,javax.xml.transform.stream,javax.xml.validation,javax.xml.ws,javax.xml.ws.handler,javax.xml.ws.handler.soap,javax.xml.ws.http,javax.xml.ws.soap,javax.xml.ws.spi,javax.xml.ws.wsaddressing,javax.xml.xpath,org.ietf.jgss,org.omg.CORBA,org.omg.CORBA_2_3,org.omg.CORBA_2_3.portable,org.omg.CORBA.DynAnyPackage,org.omg.CORBA.ORBPackage,org.omg.CORBA.portable,org.omg.CORBA.TypeCodePackage,org.omg.CosNaming,org.omg.CosNaming.NamingContextExtPackage,org.omg.CosNaming.NamingContextPackage,org.omg.Dynamic,org.omg.DynamicAny,org.omg.DynamicAny.DynAnyFactoryPackage,org.omg.DynamicAny.DynAnyPackage,org.omg.IOP,org.omg.IOP.CodecFactoryPackage,org.omg.IOP.CodecPackage,org.omg.Messaging,org.omg.PortableInterceptor,org.omg.PortableInterceptor.ORBInitInfoPackage,org.omg.PortableServer,org.omg.PortableServer.CurrentPackage,org.omg.PortableServer.POAManagerPackage,org.omg.PortableServer.POAPackage,org.omg.PortableServer.portable,org.omg.PortableServer.ServantLocatorPackage,org.omg.SendingContext,org.omg.stub.java.rmi,org.w3c.dom,org.w3c.dom.bootstrap,org.w3c.dom.css,org.w3c.dom.events,org.w3c.dom.html,org.w3c.dom.ls,org.w3c.dom.ranges,org.w3c.dom.stylesheets,org.w3c.dom.traversal,org.w3c.dom.views,org.w3c.dom.xpath,org.xml.sax,org.xml.sax.ext,org.xml.sax.helpers
org.osgi.framework.vendor=Eclipse
org.osgi.framework.version=1.5.0
org.osgi.supports.framework.extension=true
org.osgi.supports.framework.fragment=true
org.osgi.supports.framework.requirebundle=true
os.arch=i386
os.name=Linux
os.version=2.6.38-8-generic-pae
osgi.arch=x86
osgi.bundles=reference:file:javax.transaction_1.1.1.v201006150915.jar,reference:file:org.eclipse.equinox.weaving.hook_1.0.0.v20100108.jar,reference:file:org.eclipse.persistence.jpa.equinox.weaving_2.1.2.v20101206-r8635.jar,reference:file:org.eclipse.equinox.simpleconfigurator_1.0.200.v20100503.jar@1:start
osgi.bundles.defaultStartLevel=4
osgi.bundlestore=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/configuration/org.eclipse.osgi/bundles
osgi.configuration.area=file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/configuration/
osgi.framework=file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/org.eclipse.osgi_3.6.2.R36x_v20110210.jar
osgi.framework.extensions=reference:file:javax.transaction_1.1.1.v201006150915.jar,reference:file:org.eclipse.equinox.weaving.hook_1.0.0.v20100108.jar,reference:file:org.eclipse.persistence.jpa.equinox.weaving_2.1.2.v20101206-r8635.jar
osgi.framework.shape=jar
osgi.framework.version=3.6.2.R36x_v20110210
osgi.frameworkClassPath=., file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/javax.transaction_1.1.1.v201006150915.jar, file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/org.eclipse.equinox.weaving.hook_1.0.0.v20100108.jar, file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/org.eclipse.persistence.jpa.equinox.weaving_2.1.2.v20101206-r8635.jar
osgi.install.area=file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/
osgi.instance.area=file:/home/rwinch/Documents/workspace-sts-2.6.0.RELEASE/
osgi.instance.area.default=file:/home/rwinch/Documents/workspace-sts-2.6.1.RELEASE/
osgi.logfile=/home/rwinch/Documents/workspace-sts-2.6.0.RELEASE/.metadata/.log
osgi.manifest.cache=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/configuration/org.eclipse.osgi/manifests
osgi.nl=en_US
osgi.os=linux
osgi.requiredJavaVersion=1.5
osgi.splashLocation=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/com.springsource.sts_2.6.1.201105041000-RELEASE/splash.bmp
osgi.splashPath=platform:/base/plugins/com.springsource.sts
osgi.syspath=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins
osgi.tracefile=/home/rwinch/Documents/workspace-sts-2.6.0.RELEASE/.metadata/trace.log
osgi.user.area=file:/home/rwinch/user/
osgi.ws=gtk
path.separator=:
securerandom.source=file:/dev/./urandom
sun.arch.data.model=32
sun.boot.class.path=/usr/lib/jvm/jdk1.6.0_24/jre/lib/resources.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/rt.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/sunrsasign.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/jsse.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/jce.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/charsets.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/modules/jdk.boot.jar:/usr/lib/jvm/jdk1.6.0_24/jre/classes
sun.boot.library.path=/usr/lib/jvm/jdk1.6.0_24/jre/lib/i386
sun.cpu.endian=little
sun.cpu.isalist=
sun.desktop=gnome
sun.io.unicode.encoding=UnicodeLittle
sun.jnu.encoding=UTF-8
sun.management.compiler=HotSpot Client Compiler
sun.os.patch.level=unknown
user.country=US
user.dir=/home/rwinch
user.home=/home/rwinch
user.language=en
user.name=rwinch
user.timezone=America/Chicago

      • Features:
        com.atlassian.connector.eclipse.jira (2.3.0.v20100901) "Atlassian Connector for Eclipse Branding"
        com.springsource.sts (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.maven (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.package (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.patch (2.6.0.201104111100-PATCH) "SpringSource Tool Suite"
        com.springsource.sts.roo (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.server.tc (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.tutorials (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.vmware (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite"
        com.vmware.vixapi (2.6.0.201105041000-RELEASE) "Vix API Plug-in"
        org.codehaus.groovy.eclipse.feature (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin"
        org.codehaus.groovy.jdt.patch (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin"
        org.codehaus.groovy.m2eclipse (1.0.0.201102251618) "Groovy-Eclipse m2eclipse integration"
        org.codehaus.groovy17.feature (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin"
        org.codehaus.groovy18.feature (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin"
        org.eclipse.ajdt (2.1.2.e36x-20110307-1000) "AspectJ Development Tools"
        org.eclipse.cvs (1.2.1.r362_v20101111-7B77FKv99HL0GvIAF99I8H14B7E) "Eclipse CVS Client"
        org.eclipse.datatools.common.doc.user (1.8.2.v201010181125-26-311A16321A3557) "Data Tools Platform User Documentation"
        org.eclipse.datatools.connectivity.doc.user (1.8.2.v201010181125-37D-7733L3D753L7BBF) "Data Tools Platform Connectivity User Documentation"
        org.eclipse.datatools.connectivity.feature (1.8.2.v201010181125-7C7b8mEt1Zwkn9kfkUHHsoP_3to) "Data Tools Platform Connectivity Plug-in"
        org.eclipse.datatools.connectivity.oda.designer.core.feature (1.8.2.v201010181125-7B7C7ACcNBGLEOIeD_SO) "DTP ODA Designer UI Framework Plug-in"
        org.eclipse.datatools.connectivity.oda.designer.feature (1.8.2.v201010181125-4107w3121151A1A53) "DTP ODA Designer UI Framework Plug-in"
        org.eclipse.datatools.connectivity.oda.feature (1.8.2.v201010181125-7H7C7CCcNBHEDPHcETPO) "DTP Open Data Access"
        org.eclipse.datatools.doc.user (1.8.2.v201010181125-47C08w95ENAK6AFDFK7) "Data Tool Platform User Documentation"
        org.eclipse.datatools.enablement.apache.derby.feature (1.8.2.v201010181125-77778fBmKDNOMgJvJ8Of7QBR) "High-level Sybase Enablement Plug-in"
        org.eclipse.datatools.enablement.feature (1.8.2.v201010181125-7J8x7UBWwUN6z02z-fiI_w4x4uLf) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.hsqldb.feature (1.8.2.v201010181125-67C2AqGBJVKbHlH1GU7QBR) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.ibm.feature (1.8.2.v201010181125-7F47SFC7sRbrSZope9vW) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.ingres.feature (1.8.2.v201010181125-540AkF78Y7VCOCQDB) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.jdbc.feature (1.8.2.v201010181125-4-29oB56N5N7L6PAQ) "High-level Sybase Enablement Plug-in"
        org.eclipse.datatools.enablement.jdt.feature (1.8.2.v201010181125-2-07w31211518181A) "Data Tools Platform Connectivity JDT Extension Plug-in"
        org.eclipse.datatools.enablement.msft.feature (1.8.2.v201010181125-542AkF79P7QCP9SDB) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.mysql.feature (1.8.2.v201010181125-546AkF78Y7R9PAX77) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.oda.designer.feature (1.8.2.v201010181125-3328s735357795A78) "Eclipse Data Tools Platform XML ODA Designer"
        org.eclipse.datatools.enablement.oda.feature (1.8.2.v201010181125-7A7T78DZRDKDFbGwFjNK) "Eclipse Data Tools Platform XML ODA Runtime Driver"
        org.eclipse.datatools.enablement.oracle.feature (1.8.2.v201010181125-548dAkF79Q7RAN9UEE) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.postgresql.feature (1.8.2.v201010181125-542AkF77g7V9N9e77) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.sap.feature (1.8.2.v201010181125-540AkF77g7V9N9e77) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.sqlite.feature (1.8.2.v201010181125-541AkF79P7N8NAQ77) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.sybase.feature (1.8.2.v201010181125-7E45F9NiNZVR6a1PMVn) "High-level Sybase Enablement Plug-in"
        org.eclipse.datatools.intro (1.8.2.v201010181125-26-7w312116392911) "Eclipse Data Tools Platform Intro Plug-in"
        org.eclipse.datatools.modelbase.feature (1.8.2.v201010181125-77078CcNBGKBZI_FcRd) "Eclipse Data Tools Platform SQLModel Plug-in"
        org.eclipse.datatools.sqldevtools.ddlgen.feature (1.8.2.v201010181125-7A-3F7RZHLz-Hz-OlPz0Qf) "Eclipse Data Tools Platform FE UI Plug-in"
        org.eclipse.datatools.sqldevtools.feature (1.8.2.v201010181125-7N7y7JFDrhqbGIFUNhcFodMMD2J0) "Eclipse Data Tools Platform SQL Tools Common UI Plug-in"
        org.eclipse.datatools.sqldevtools.parsers.feature (1.8.2.v201010181125-622BgJ9CR9XFcEWLP) "Eclipse Data Tools Platform SQL Parser Plugin"
        org.eclipse.datatools.sqltools.doc.user (1.8.2.v201010181125-37D-7733L3D753L7BBF) "Data Tools Platform SQL Tools User Documentation"
        org.eclipse.draw2d (3.6.2.v20110128-0100-4517w3122123901211) "Graphical Editing Framework Draw2d"
        org.eclipse.egit (0.12.1) "Git Team Provider (Incubation)"
        org.eclipse.emf (2.6.1.v20100914-1218) "EMF - Eclipse Modeling Framework Runtime and Tools"
        org.eclipse.emf.codegen (2.6.0.v20100914-1218) "EMF Code Generation"
        org.eclipse.emf.codegen.ecore (2.6.1.v20100914-1218) "EMF Ecore Code Generator"
        org.eclipse.emf.codegen.ecore.ui (2.6.0.v20100914-1218) "EMF Ecore Code Generator UI"
        org.eclipse.emf.codegen.ui (2.6.0.v20100914-1218) "EMF Code Generation UI"
        org.eclipse.emf.common (2.6.0.v20100914-1218) "EMF Common"
        org.eclipse.emf.common.ui (2.6.0.v20100914-1218) "EMF Common UI"
        org.eclipse.emf.converter (2.6.0.v20100914-1218) "EMF Model Converter"
        org.eclipse.emf.databinding (1.2.0.v20100914-1218) "EMF Data Binding"
        org.eclipse.emf.databinding.edit (1.2.0.v20100914-1218) "EMF Edit Data Binding"
        org.eclipse.emf.ecore (2.6.1.v20100914-1218) "EMF Ecore"
        org.eclipse.emf.ecore.edit (2.6.0.v20100914-1218) "EMF Ecore Edit"
        org.eclipse.emf.ecore.editor (2.6.0.v20100914-1218) "EMF Sample Ecore Editor"
        org.eclipse.emf.edit (2.6.0.v20100914-1218) "EMF Edit"
        org.eclipse.emf.edit.ui (2.6.0.v20100914-1218) "EMF Edit UI"
        org.eclipse.emf.mapping (2.6.0.v20100914-1218) "EMF Mapping"
        org.eclipse.emf.mapping.ecore (2.6.0.v20100914-1218) "EMF Ecore Mapping"
        org.eclipse.emf.mapping.ecore.editor (2.6.0.v20100914-1218) "EMF Ecore Mapping Editor"
        org.eclipse.emf.mapping.ui (2.6.0.v20100914-1218) "EMF Mapping UI"
        org.eclipse.gef (3.6.2.v20110128-0100-777B381A4Bz06565376E32322) "Graphical Editing Framework GEF"
        org.eclipse.help (1.2.1.r362_v20101111-7e7jEVFDr6xg-LSlC_z0w1D) "Help System Base"
        org.eclipse.jdt (3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F) "Eclipse Java Development Tools"
        org.eclipse.jgit (0.12.1) "JGit Core (Incubation)"
        org.eclipse.jpt.eclipselink.feature (2.3.3.v201102072310-7778BkBgJ9EA9VGcDFBA) "Dali Java Persistence Tools - EclipseLink Support"
        org.eclipse.jpt.feature (2.3.3.v201010220000-7N7UF77FD3wTgcVbmmf0cT) "Dali Java Persistence Tools"
        org.eclipse.jst.common.fproj.enablement.jdt (3.2.2.v201008170019-377AB8s73533J5J759F) "Eclipse Faceted Project Framework JDT Enablement"
        org.eclipse.jst.enterprise_ui.feature (3.2.3.v201011031800-7b7GHfIFSK2WBRT6E1mcyFXGPnSh) "Eclipse Java EE Developer Tools"
        org.eclipse.jst.ws.axis2tools.feature (1.1.100.v201005241530-78-FF0DZRDKDDePSKwHj) "Axis2 Tools"
        org.eclipse.mylyn_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.bugzilla_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.context_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.ide_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.java_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.jira_feature (3.4.0) "Atlassian Connector for Eclipse Branding"
        org.eclipse.mylyn.team_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.wikitext_feature (1.4.0.v20110316-0100) "Mylyn"
        org.eclipse.pde (3.6.2.r362_v20110203-7b7mFL2FET3dhHalh1iNZtL) "PDE"
        org.eclipse.persistence.jpa (2.1.2.v20101206-r8635) "EclipseLink JPA"
        org.eclipse.persistence.moxy (2.1.2.v20101206-r8635) "EclipseLink MOXy"
        org.eclipse.persistence.sdo (2.1.2.v20101206-r8635) "EclipseLink SDO"
        org.eclipse.platform (3.6.2.r362_v20110210-9gF78Gs1FrIGnHDHWkEcopoN8AmxeZflGDGKQi) "Eclipse Platform"
        org.eclipse.rcp (3.6.2.r362_v20101104-9SAxFMKFkSAqi8axkv1ZjegmiBLY) "Eclipse RCP"
        org.eclipse.rse (3.2.2.R32x_v201102130925-7L78FA58SreKCHr_JG7UA8bra19p) "Remote System Explorer End-User Runtime"
        org.eclipse.rse.core (3.2.2.R32x_v201102011435-7a7FFMcF9hxfDPvGY6d8rTEETOY) "RSE Core"
        org.eclipse.rse.dstore (3.2.2.R32x_v201102011435-7L77FDBD2YO5DwmNgNdOG98LBL) "RSE DStore Services"
        org.eclipse.rse.ftp (3.0.200.v201005221100-780Bg9oB56N5J9QBADD) "RSE FTP Service"
        org.eclipse.rse.local (2.1.202.R32x_v201102011435-7B4F8QBCKC5H2XIVHMB922546) "RSE Local Services"
        org.eclipse.rse.ssh (3.0.100.v201005221100-7A2BhAkF77g7VEYDG7C) "RSE SSH Services"
        org.eclipse.rse.telnet (2.2.100.v201005221100-7730AkF77g7UDXELEF) "RSE Telnet Service"
        org.eclipse.rse.terminals (1.0.102.R32x_v201102011435-77-DI9uCFjNZVBGlDNC332423365) "RSE Terminals UI"
        org.eclipse.rse.useractions (1.1.200.v201005221100-31A78s733L3D7H7933) "Remote System Explorer User Actions"
        org.eclipse.team.svn (0.7.9.I20110523-1700) "Subversive SVN Team Provider (Incubation)"
        org.eclipse.team.svn.mylyn (0.7.9.I20110523-1700) "Subversive Integration for the Mylyn Project (Incubation)"
        org.eclipse.team.svn.resource.ignore.rules.jdt (0.7.9.I20110523-1700) "Subversive JDT Ignore Extensions (Incubation)"
        org.eclipse.tm.terminal (3.0.202.R32x_v201102011435-4-8a7S43yaw312213122546) "Target Management Terminal Widget"
        org.eclipse.tm.terminal.ssh (2.0.200.v201005271030-3-A77w312116382141) "Target Management Terminal SSH Connector"
        org.eclipse.tm.terminal.telnet (2.0.200.v201005032000-3-8_7w311A1A271116) "Target Management Terminal Telnet Connector"
        org.eclipse.tm.terminal.view (2.1.2.R32x_v201102011435-3017S43yaw312213122546) "Target Management Terminal View"
        org.eclipse.wst.common.fproj (3.2.3.v201101121727-377AC8s73543C6H4A5H) "Eclipse Faceted Project Framework"
        org.eclipse.wst.jsdt.feature (1.2.3.v201102160540-7C78FGUF9JgLWNO2UCNqfa) "Eclipse JavaScript Development Tools"
        org.eclipse.wst.web_ui.feature (3.2.3.v201102160541-7O7CFbWEMf84qYjGDyP3DNEwcgFU) "Eclipse Web Developer Tools"
        org.eclipse.wst.xml_ui.feature (3.2.3.v201102160550-7H7AFUWDxumQJOi9ghcTb5YgkwEZ) "Eclipse XML Editors and Tools"
        org.eclipse.wst.xml.xpath2.processor.feature (1.1.6.v201101212357-67K3BgJ9DJAPEUCSKQ) "Eclipse XPath 2 Developers Tools"
        org.eclipse.wst.xsl.feature (1.1.3.v201102102045-7S7WFASFIpS-21NUD58xfPVDTLR) "Eclipse XSL Developer Tools"
        org.eclipse.zest (1.2.0.v20100519-2050-67818yE6F-AA7P4B8I52322) "Graphical Editing Framework Zest Core"
        org.maven.ide.eclipse.ajdt.feature (0.10.0.20100209-0800) "Maven Integration for Eclipse"
        org.maven.ide.eclipse.feature (0.12.1.20110112-1712) "Maven Integration for Eclipse"
        org.maven.ide.eclipse.temporary.mojos.feature (0.12.0.20101103-1500) "Maven Integration for Eclipse"
        org.maven.ide.eclipse.wtp.feature (0.11.1.20101108-1810) "Maven Integration for Eclipse"
        org.polarion.eclipse.team.svn.connector (2.2.2.I20110523-1700) "Subversive SVN Connectors"
        org.polarion.eclipse.team.svn.connector.javahl16 (2.2.2.I20110523-1700) "Subversive SVN 1.6 JavaHL Connector"
        org.polarion.eclipse.team.svn.connector.svnkit16 (2.2.2.I20110523-1700) "Subversive SVN 1.6 SVN Kit Connector"
        org.springframework.ide.eclipse.ajdt.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.aop.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.autowire.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.batch.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.integration.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.mylyn.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.osgi.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.security.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.webflow.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.zeroturnaround.eclipse.feature (1.4.1.201106011212) "JRebel Eclipse Plug-in"
        org.zeroturnaround.eclipse.wtp.feature (1.4.0.201105311642) "JRebel WTP Integration Plug-in"
      • Plug-in Registry:
        com.atlassian.connector.eclipse.branding.ui (2.3.0.v20100901) "Atlassian Connector for Eclipse Branding" [Active]
        com.atlassian.connector.eclipse.commons.core (2.3.0.v20100901) "Atlassian Connector for Eclipse Commons Core" [Active]
        com.atlassian.connector.eclipse.commons.ui (2.3.0.v20100901) "Atlassian Connector for Eclipse UI Commons" [Active]
        com.atlassian.connector.eclipse.jira.core (2.3.0.v20100901) "Atlassian Connector for Eclipse Jira Core" [Active]
        com.atlassian.connector.eclipse.jira.ui (2.3.0.v20100901) "Atlassian Connector for Eclipse JIRA UI" [Active]
        com.caucho.hessian (3.2.0) "Caucho Hessian Plug-in" [Resolved]
        com.ibm.icu (4.2.1.v20100412) "International Components for Unicode for Java (ICU4J)" [Active]
        com.jcraft.jsch (0.1.41.v200903070017) "JSch" [Resolved]
        com.lowagie.text (2.1.7.v201004222200) "Lowagie iText" [Resolved]
        com.springsource.javax.el (1.0.0) "Java Expression Language API" [Resolved]
        com.springsource.javax.jms (1.1.0) "Java Messaging System API" [Resolved]
        com.springsource.javax.servlet (2.5.0) "Java Servlet API" [Resolved]
        com.springsource.javax.servlet.jsp (2.1.0) "Java JSP API" [Resolved]
        com.springsource.javax.servlet.jsp.jstl (1.2.0) "Java JSP Standard Tag Library" [Resolved]
        com.springsource.org.antlr (3.0.1) "ANTLR" [Resolved]
        com.springsource.org.apache.myfaces.javax.faces (1.2.2) "Apache MyFaces JSF API" [Resolved]
        com.springsource.org.aspectj.weaver (1.6.10.RELEASE) "AspectJ Weaver" [Resolved]
        com.springsource.org.objectweb.asm (2.2.3) "ObjectWeb ASM" [Resolved]
        com.springsource.org.objectweb.asm.commons (2.2.3) "ObjectWeb ASM Commons" [Resolved]
        com.springsource.sts (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite" [Active]
        com.springsource.sts.bestpractices (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Best Practices" [Starting]
        com.springsource.sts.config.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Spring Configuration Editor (Core)" [Active]
        com.springsource.sts.config.flow (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Configuration Flow Editing" [Active]
        com.springsource.sts.config.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Spring Configuration Editor (UI)" [Active]
        com.springsource.sts.content.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Content (Core)" [Active]
        com.springsource.sts.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite (Core)" [Active]
        com.springsource.sts.frameworks.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Framework Support Core" [Active]
        com.springsource.sts.frameworks.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Framework Support (UI)" [Active]
        com.springsource.sts.ide.configurator (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Workspace Configuration" [Active]
        com.springsource.sts.ide.help (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Help and Support" [Active]
        com.springsource.sts.ide.metadata (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Spring Meta Data Extension" [Active]
        com.springsource.sts.ide.osgi (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite OSGi Runtime Support" [Active]
        com.springsource.sts.ide.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite (UI)" [Active]
        com.springsource.sts.maven (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Maven Integration" [Active]
        com.springsource.sts.quickfix (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Quick Fixes" [Active]
        com.springsource.sts.roo.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Roo Integration (Core)" [Active]
        com.springsource.sts.roo.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Roo Integration (UI)" [Active]
        com.springsource.sts.server.commons.vmware.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite VMware Workstation Integration (Core)" [Starting]
        com.springsource.sts.server.commons.vmware.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite VMware Workstation Integration (UI)" [Starting]
        com.springsource.sts.server.insight.ui (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite tc Server Spring Insight Integration" [Active]
        com.springsource.sts.server.tc.core (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite tc Server Integration (Core)" [Resolved]
        com.springsource.sts.server.tc.reloading (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite tc Server Agent Reloading" [Starting]
        com.springsource.sts.server.tc.ui (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite tc Server Integration (UI)" [Starting]
        com.springsource.sts.server.tc.vmware.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite tc Server VMware Workstation Integration (Core)" [Starting]
        com.springsource.sts.server.tc.vmware.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite tc Server VMware Workstation Integration (UI)" [Starting]
        com.springsource.sts.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite (UI)" [Active]
        com.springsource.sts.vmware.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite VMware Integration (Core)" [Resolved]
        com.springsource.sts.vmware.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite VMware Integration (UI)" [Starting]
        com.springsource.sts.wizard (2.6.0.201105041000-RELEASE) "Wizard Plug-in" [Active]
        com.springsource.util.common (2.0.0.RELEASE) "Common Utility Code" [Resolved]
        com.sun.syndication (0.9.0.v200803061811) "Rss and atOM utilitiEs (ROME)" [Resolved]
        com.vmware.vixapi (2.6.0.201105041000-RELEASE) "Vix API Plug-in" [Starting]
        commonj.sdo (2.1.1.v200905221342) "SDO API" [Starting]
        edu.emory.mathcs.backport (3.1.0.v200902251154) "JSR166 java.util.concurrency backport" [Resolved]
        java_cup.runtime (0.10.0.v201005080400) "Java Cup" [Resolved]
        javax.activation (1.1.0.v201005080500) "Apache Geronimo Activation Plug-in" [Resolved]
        javax.annotation (1.1.1.v201006150915) "geronimo jta 1.1 spec" [Resolved]
        javax.mail (1.4.0.v201005080615) "Javax Mail Plug-in" [Resolved]
        javax.persistence (2.0.1.v201006031150) "Java Persistence API 2.0" [Resolved]
        javax.servlet (2.5.0.v200910301333) "Servlet API Bundle" [Resolved]
        javax.servlet.jsp (2.0.0.v200806031607) "Java Server Pages API Bundle" [Resolved]
        javax.transaction (1.1.1.v201006150915) "geronimo annotation 1.0 spec" [Resolved]
        javax.wsdl (1.5.1.v201005080630) "WSDL4J" [Resolved]
        javax.wsdl (1.6.2.v201005080631) "WSDL4J" [Resolved]
        javax.xml (1.3.4.v201005080400) "JAXP XML" [Resolved]
        javax.xml.bind (2.2.0.v201005080402) "XML Binding for Java" [Resolved]
        javax.xml.rpc (1.1.0.v201005080400) "JAX-RPC" [Resolved]
        javax.xml.soap (1.2.0.v201005080501) "SAAJ" [Resolved]
        javax.xml.soap (1.3.0.v201005080502) "SAAJ" [Resolved]
        javax.xml.stream (1.0.1.v201004272200) "Java XML Streaming API" [Resolved]
        net.sourceforge.lpg.lpgjavaruntime (1.1.0.v201004271650) "SourceForge LPG" [Resolved]
        org.aopalliance (1.0.0.v200905130917) "Aopalliance Plug-in" [Resolved]
        org.apache.ant (1.7.1.v20100518-1145) "Apache Ant" [Resolved]
        org.apache.axis (1.4.0.v201005080400) "Apache Web Services" [Resolved]
        org.apache.bcel (5.2.0.v201005080400) "Apache BCEL" [Resolved]
        org.apache.commons.codec (1.3.0.v20100518-1140) "Apache Commons Codec Plug-in" [Resolved]
        org.apache.commons.collections (3.2.0.v201005080500) "Apache Commons Collections" [Resolved]
        org.apache.commons.discovery (0.2.0.v201004190315) "Jakarta-Commons Discovery" [Resolved]
        org.apache.commons.el (1.0.0.v201004212143) "Apache Commons JSP 2.0 Expression Language Interpreter" [Resolved]
        org.apache.commons.httpclient (3.1.0.v201005080502) "Apache Commons Httpclient" [Resolved]
        org.apache.commons.io (2.0.1.v201101200200) "pluginName" [Resolved]
        org.apache.commons.lang (2.1.0.v201005080500) "Apache Jakarta Commons Lang" [Resolved]
        org.apache.commons.lang (2.4.0.v201005080502) "Apache Jakarta Commons Lang" [Resolved]
        org.apache.commons.logging (1.0.4.v201005080501) "Apache Commons Logging Plug-in" [Resolved]
        org.apache.commons.logging (1.1.1.v201005080502) "Apache Commons Logging Plug-in" [Resolved]
        org.apache.commons.net (2.0.0.v200905272248) "Apache Commons Net" [Resolved]
        org.apache.derby (10.5.1.1_201005192117) "Apache Derby Plug-in" [Starting]
        org.apache.jasper (5.5.17.v201004212143) "Apache Jasper 2 Plug-in" [Resolved]
        org.apache.log4j (1.2.15.v201005080500) "Apache Jakarta log4j Plug-in" [Resolved]
        org.apache.lucene (1.9.1.v20100518-1140) "Apache Lucene" [Resolved]
        org.apache.lucene.analysis (1.9.1.v20100518-1140) "Apache Lucene Analysis" [Resolved]
        org.apache.oro (2.0.8.v201005080400) "Apache Jakarta ORO" [Resolved]
        org.apache.velocity (1.5.0.v200905192330) "Apache Velocity Plug-in" [Resolved]
        org.apache.ws.commons.schema (1.4.2.v201003051240) "Apache WS Commons XMLSchema Plug-in" [Resolved]
        org.apache.ws.commons.util (1.0.1.v20100518-1140) "WS Commons Util Plug-in" [Resolved]
        org.apache.wsil4j (1.0.0.v200901211807) "WSIL4J" [Resolved]
        org.apache.xalan (2.7.1.v201005080400) "Xalan-Java" [Resolved]
        org.apache.xerces (2.9.0.v201005080400) "Apache Xerces-J" [Resolved]
        org.apache.xml.resolver (1.2.0.v201005080400) "Apache XmlResolver" [Resolved]
        org.apache.xml.serializer (2.7.1.v201005080400) "Apache XML Commons Serializer" [Resolved]
        org.apache.xmlrpc (3.0.0.v20100427-1100) "Apache XML-RPC Plug-in" [Resolved]
        org.aspectj.ajde (1.6.11.20110304135300) "AspectJ" [Active]
        org.aspectj.runtime (1.6.11.20110304135300) "AspectJ Runtime" [Resolved]
        org.aspectj.weaver (1.6.11.20110304135300) "AspectJ Weaver" [Resolved]
        org.codehaus.groovy (1.7.10.xx-20110602-1000-e36) "Groovy Runtime Plug-in" [Active]
        org.codehaus.groovy (1.8.0.xx-20110602-1000-e36) "Groovy Runtime Plug-in" [Installed]
        org.codehaus.groovy.eclipse (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin" [Resolved]
        org.codehaus.groovy.eclipse.ant (2.5.1.xx-20110602-1000-e36) "Groovy-Ant Plug-in" [Starting]
        org.codehaus.groovy.eclipse.astviews (2.5.1.xx-20110602-1000-e36) "Groovy AST Views" [Starting]
        org.codehaus.groovy.eclipse.codeassist.completion (2.5.1.xx-20110602-1000-e36) "Code Completion Plug-in" [Active]
        org.codehaus.groovy.eclipse.codebrowsing (2.5.1.xx-20110602-1000-e36) "Groovy Code Browsing" [Starting]
        org.codehaus.groovy.eclipse.core (2.5.1.xx-20110602-1000-e36) "Groovy Core" [Active]
        org.codehaus.groovy.eclipse.dsl (2.5.1.xx-20110602-1000-e36) "Groovy DSL support" [Active]
        org.codehaus.groovy.eclipse.quickfix (2.5.1.xx-20110602-1000-e36) "Groovy Quick Fix" [Active]
        org.codehaus.groovy.eclipse.refactoring (2.5.1.xx-20110602-1000-e36) "Groovy Refactoring Plug-in" [Active]
        org.codehaus.groovy.eclipse.ui (2.5.1.xx-20110602-1000-e36) "Groovy UI" [Active]
        org.codehaus.groovy.m2eclipse (1.0.0.201102251618) "Groovy-Eclipse m2eclipse integration" [Active]
        org.eclipse.ajdt.core (2.1.2.e36x-20110307-1000) "AspectJ Development Tools Core" [Active]
        org.eclipse.ajdt.doc.user (2.1.2.e36x-20110307-1000) "AspectJ Development Tools User Documentation" [Resolved]
        org.eclipse.ajdt.examples (2.1.2.e36x-20110307-1000) "AspectJ Examples" [Starting]
        org.eclipse.ajdt.mylyn.ui (2.1.2.e36x-20110307-1000) "Mylyn-AJDT Bridge Plug-in" [Active]
        org.eclipse.ajdt.ui (2.1.2.e36x-20110307-1000) "AspectJ Development Tools UI" [Active]
        org.eclipse.ant.core (3.2.201.v20110203_r362) "Ant Build Tool Core" [Starting]
        org.eclipse.ant.launching (1.0.1.v20101020_r362) "Ant Launching Support" [Starting]
        org.eclipse.ant.ui (3.5.0.v20100427) "Ant UI" [Active]
        org.eclipse.aspectj (2.1.2.e36x-20110307-1000) "AspectJ Development Tools" [Starting]
        org.eclipse.compare (3.5.101.R36x_v20100929-0800) "Compare Support" [Active]
        org.eclipse.compare.core (3.5.101.R36x_v20100929-0800) "Core Compare Support" [Active]
        org.eclipse.contribution.visualiser (2.2.0.e36x-20110307-1000) "Visualiser Plug-in" [Starting]
        org.eclipse.contribution.weaving.jdt (2.1.2.e36x-20110307-1000) "JDT Weaving" [Active]
        org.eclipse.contribution.xref.core (2.1.2.e36x-20110307-1000) "Cross Reference Core Plugin" [Starting]
        org.eclipse.contribution.xref.ui (2.1.2.e36x-20110307-1000) "Cross Reference UI Plugin" [Starting]
        org.eclipse.core.boot (3.1.200.v20100505) "Core Boot" [Starting]
        org.eclipse.core.commands (3.6.0.I20100512-1500) "Commands" [Resolved]
        org.eclipse.core.contenttype (3.4.100.v20100505-1235) "Eclipse Content Mechanism" [Active]
        org.eclipse.core.databinding (1.3.100.I20100601-0800) "JFace Data Binding" [Starting]
        org.eclipse.core.databinding.beans (1.2.100.I20100601-0800) "JFace Data Binding for JavaBeans" [Resolved]
        org.eclipse.core.databinding.observable (1.3.0.I20100601-0800) "JFace Data Binding Observables" [Active]
        org.eclipse.core.databinding.property (1.3.0.I20100601-0800) "JFace Data Binding" [Starting]
        org.eclipse.core.expressions (3.4.200.v20100505) "Expression Language" [Active]
        org.eclipse.core.externaltools (1.0.1.v20100831_r361) "External Tools Headless Support" [Starting]
        org.eclipse.core.filebuffers (3.5.100.v20100520-0800) "File Buffers" [Active]
        org.eclipse.core.filesystem (1.3.1.R36x_v20100727-0745) "Core File Systems" [Active]
        org.eclipse.core.filesystem.linux.x86 (1.4.0.v20100505-1235) "Core File System for Linux" [Resolved]
        org.eclipse.core.jobs (3.5.1.R36x_v20100824) "Eclipse Jobs Mechanism" [Active]
        org.eclipse.core.net (1.2.100.I20100511-0800) "Internet Connection Management" [Active]
        org.eclipse.core.net.linux.x86 (1.1.100.R36x_v20100825-0800) "Proxy for Linux" [Resolved]
        org.eclipse.core.resources (3.6.1.R36x_v20110131-1630) "Core Resource Management" [Active]
        org.eclipse.core.runtime (3.6.0.v20100505) "Core Runtime" [Active]
        org.eclipse.core.runtime.compatibility (3.2.100.v20100505) "Core Runtime Plug-in Compatibility" [Active]
        org.eclipse.core.runtime.compatibility.auth (3.2.200.v20100517) "Authorization Compatibility Plug-in" [Active]
        org.eclipse.core.runtime.compatibility.registry (3.3.0.v20100520) "Eclipse Registry Compatibility Fragment" [Resolved]
        org.eclipse.core.variables (3.2.400.v20100505) "Core Variables" [Active]
        org.eclipse.cvs (1.0.500.v201102101200) "Eclipse CVS Client" [Starting]
        org.eclipse.datatools.common.doc.user (1.7.0.20090521092446) "Data Tools Platform User Documentation" [Starting]
        org.eclipse.datatools.connectivity (1.2.2.v201010220354) "Data Tools Platform Connectivity Plug-in" [Active]
        org.eclipse.datatools.connectivity.apache.derby (1.0.100.v200906020900) "Eclipse Data Tools Platform Derby Plug-in" [Active]
        org.eclipse.datatools.connectivity.apache.derby.dbdefinition (1.0.2.v200906161815) "Eclipse Data Tools Platform Apache Derby Database Definition" [Starting]
        org.eclipse.datatools.connectivity.apache.derby.ui (1.0.3.v201007080903) "Eclipse Data Tools Platform Apache Derby UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.console.profile (1.0.0.v200906020553) "DTP Connection Profiles Storage File Editor Plug-in" [Starting]
        org.eclipse.datatools.connectivity.db.generic (1.0.1.v200908130547) "Eclipse Data Tools Platform Generic DB Connectivity Plug-in" [Starting]
        org.eclipse.datatools.connectivity.db.generic.ui (1.0.1.v201004070709) "Eclipse Data Tools Platform Generic DB UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.dbdefinition.genericJDBC (1.0.1.v200906161815) "Eclipse Data Tools Platform DBDefinition Generic JDBC Plug-in" [Starting]
        org.eclipse.datatools.connectivity.doc.user (1.7.0.20090521092446) "Data Tools Platform Connectivity User Documentation" [Starting]
        org.eclipse.datatools.connectivity.doc.user.contexts (1.7.0.20090521092446) "Data Tools Platform Connectivity User Documentation for context-sensitive help" [Starting]
        org.eclipse.datatools.connectivity.oda (3.3.1.v201102051100) "DTP Open Data Access" [Starting]
        org.eclipse.datatools.connectivity.oda.consumer (3.2.3.v201102051100) "DTP ODA Consumer Helper Component Plug-in" [Starting]
        org.eclipse.datatools.connectivity.oda.design (3.3.2.v201012150951) "DTP ODA Design Session Model" [Starting]
        org.eclipse.datatools.connectivity.oda.design.ui (3.2.4.v201012150951) "DTP ODA Designer UI Framework Plug-in" [Starting]
        org.eclipse.datatools.connectivity.oda.flatfile (3.1.1.v201101261130) "Eclipse Data Tools Platform Flat File ODA Runtime Driver" [Starting]
        org.eclipse.datatools.connectivity.oda.flatfile.ui (3.1.1.v201101261130) "Eclipse Data Tools Platform Flat File ODA Designer" [Starting]
        org.eclipse.datatools.connectivity.oda.profile (3.2.4.v201007150318) "DTP ODA Connection Profile Framework Plug-in" [Starting]
        org.eclipse.datatools.connectivity.oda.template.ui (3.2.1.v201004090942) "DTP ODA New Plug-in Template Wizard" [Starting]
        org.eclipse.datatools.connectivity.sqm.core (1.2.1.v201010090204) "Eclipse Data Tools Platform SQM Core Plug-in" [Active]
        org.eclipse.datatools.connectivity.sqm.core.ui (1.2.0.v201002281800) "Eclipse Data Tools Platform SQM UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.sqm.server.ui (1.1.100.v201009280455) "Eclipse Data Tools Platform Server UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.ui (1.2.1.v201010211415) "Data Tools Platform Connectivity UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.ui.dse (1.1.4.v201004270430) "Eclipse Data Tools Platform Data Source Explorer Plug-in" [Starting]
        org.eclipse.datatools.doc.user (1.7.0.20090521092446) "Data Tool Platform User Documentation" [Starting]
        org.eclipse.datatools.enablement.finfo (1.5.1.v200906161800) "Eclipse Data Tools Platform Enablement" [Starting]
        org.eclipse.datatools.enablement.hsqldb (1.0.0.v200906020900) "Eclipse Data Tools Platform HSQLDB Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.hsqldb.dbdefinition (1.0.0.v200906161800) "Eclipse Data Tools Platform HSQLDB Database Definition Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.hsqldb.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform HSQLDB UI Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.iseries (1.0.2.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB iSeries Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.iseries.dbdefinition (1.0.3.v200906161800) "DB2 UDB iSeries Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.iseries.ui (1.0.1.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB UI iSeries Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.luw (1.0.2.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB LUW Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.luw.dbdefinition (1.0.4.v201005211215) "Eclipse Data Tools Platform DB2 UDB Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.luw.ui (1.0.2.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB LUW UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.zseries (1.0.2.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB zSeries Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.zseries.dbdefinition (1.0.4.v201005211230) "DB2 UDB Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.zseries.ui (1.0.1.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB zSeries UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.informix (1.0.1.v201005211230) "Eclipse Data Tools Platform Informix Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.informix.dbdefinition (1.0.4.v201005211230) "Eclipse Data Tools Platform Informix Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.informix.ui (1.0.2.v201005211230) "Eclipse Data Tools Platform Informix UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform IBM UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.ingres (1.0.0.v200906111150) "Ingres DTP Plug-in" [Starting]
        org.eclipse.datatools.enablement.ingres.dbdefinition (1.0.0.v200906161800) "Ingres DTP Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ingres.ui (1.0.0.v201006242214) "Ingres DTP UI Plug-in" [Active]
        org.eclipse.datatools.enablement.jdt.classpath (1.0.1.v201004070709) "Data Tools Platform Connectivity JDT Extension Plug-in" [Starting]
        org.eclipse.datatools.enablement.msft.sqlserver (1.0.1.v201001180222) "Eclipse Data Tools Platform Microsoft SQL Server Plug-in" [Active]
        org.eclipse.datatools.enablement.msft.sqlserver.dbdefinition (1.0.0.v201004211630) "Eclipse Data Tools Platform SQL Server Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.msft.sqlserver.ui (1.0.1.v200908130512) "Eclipse Data Tools Platform Microsoft SQL Server UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.mysql (1.0.2.v201002041100) "Eclipse Data Tools Platform MySQL Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.mysql.dbdefinition (1.0.4.v200906161800) "Eclipse Data Tools Platform MySQL Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.mysql.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform MySQL UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.oda.ws (1.2.2.v201010151422) "Eclipse Data Tools Platform Web Services ODA Runtime Driver" [Starting]
        org.eclipse.datatools.enablement.oda.ws.ui (1.2.2.v201012301630) "Eclipse Data Tools Platform Web Services ODA Designer" [Starting]
        org.eclipse.datatools.enablement.oda.xml (1.2.1.v201010211755) "Eclipse Data Tools Platform XML ODA Runtime Driver" [Starting]
        org.eclipse.datatools.enablement.oda.xml.ui (1.2.1.v201012161115) "Eclipse Data Tools Platform XML ODA Designer" [Starting]
        org.eclipse.datatools.enablement.oracle (1.0.0.v200908130544) "Eclipse Data Tools Platform Oracle Plug-in" [Active]
        org.eclipse.datatools.enablement.oracle.dbdefinition (1.0.102.v201101120730) "Eclipse Data Tools Platform Oracle Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.oracle.ui (1.0.2.v201005051303) "Eclipse Data Tools Platform Oracle UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.postgresql (1.0.1.v200906020900) "PostgreSQL Connection Profile and Driver Template Plug-in" [Starting]
        org.eclipse.datatools.enablement.postgresql.dbdefinition (1.0.1.v200906161800) "PostgreSQL DB Definition" [Starting]
        org.eclipse.datatools.enablement.postgresql.ui (1.0.0.v200906020900) "PostgreSQL Connection Profile and Driver Template UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.sap.maxdb (1.0.0.v200906020900) "Eclipse Data Tools Platform MaxDB Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.sap.maxdb.dbdefinition (1.0.0.v200906161800) "Eclipse Data Tools Platform MaxDB Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.sap.maxdb.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform MaxDB UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.sqlite (1.0.0.v201002041100) "Eclipse Data Tools Platform SQLite Enablement Plug-in" [Active]
        org.eclipse.datatools.enablement.sqlite.dbdefinition (1.0.1.v201002041100) "Eclipse Data Tools Platform SQLite Database Definition Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.sqlite.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform SQLite UI Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase (1.0.1.v200906020900) "High-level Sybase Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase.asa (1.0.1.v200906020900) "Sybase ASA Plug-in" [Active]
        org.eclipse.datatools.enablement.sybase.asa.dbdefinition (1.0.0.v200906161800) "Eclipse Data Tools Platform Sybase ASA Database Definition" [Starting]
        org.eclipse.datatools.enablement.sybase.asa.models (1.0.0.v201010140307) "Sybase ASA SQL Model" [Active]
        org.eclipse.datatools.enablement.sybase.asa.schemaobjecteditor.examples (2.5.0.200810071) "Sybase ASA Schema Object Editor" [Active]
        org.eclipse.datatools.enablement.sybase.asa.ui (1.0.1.v200906111150) "Sybase ASA Connection Profile UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase.ase (1.0.1.v200906020900) "JDBC/Sybase ASE Connection Profile Plug-in" [Active]
        org.eclipse.datatools.enablement.sybase.ase.dbdefinition (1.0.0.v200906161800) "Eclipse Data Tools Platform Sybase ASE Database Definition" [Starting]
        org.eclipse.datatools.enablement.sybase.ase.models (1.0.1.v201010140307) "Sybase ASE Model Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase.ase.ui (1.0.1.v200906020900) "ASE Enablement UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase.models (1.0.0.v201010140307) "Sybase Model Plug-in" [Active]
        org.eclipse.datatools.enablement.sybase.ui (1.0.0.v200906090458) "Sybase UI Plug-in" [Starting]
        org.eclipse.datatools.help (1.5.0.v200906020553) "Data Tools Platform Help Utilities" [Resolved]
        org.eclipse.datatools.intro (1.7.0.v201005281800) "Eclipse Data Tools Platform Intro Plug-in" [Resolved]
        org.eclipse.datatools.modelbase.dbdefinition (1.0.2.v201002130228) "Eclipse Data Tools Platform DBDefinition Model" [Starting]
        org.eclipse.datatools.modelbase.derby (1.0.0.v201002161452) "Eclipse Data Tools Platform Derby Model Plug-in" [Starting]
        org.eclipse.datatools.modelbase.sql (1.0.4.v201002250945) "Eclipse Data Tools Platform SQLModel Plug-in" [Active]
        org.eclipse.datatools.modelbase.sql.edit (1.0.1.v201002161452) "Eclipse Data Tools Platform SQLModel Edit Plug-in" [Starting]
        org.eclipse.datatools.modelbase.sql.query (1.1.1.v201008100700) "Eclipse Data Tools Platform SQL Query Model Plugin" [Starting]
        org.eclipse.datatools.modelbase.sql.query.edit (1.0.0.v200906022249) "SQL Query Edit Support Plugin" [Starting]
        org.eclipse.datatools.modelbase.sql.xml.query (1.0.1.v201004291415) "Eclipse Data Tools Platform SQL XML Query Model Plugin" [Starting]
        org.eclipse.datatools.oda.cshelp (1.1.1.v200907031118) "DTP ODA Context-sensitive Help" [Starting]
        org.eclipse.datatools.sqltools.common.ui (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL Tools Common UI Plug-in" [Active]
        org.eclipse.datatools.sqltools.data.core (1.2.0.v201005241300) "Data Core Plugin" [Starting]
        org.eclipse.datatools.sqltools.data.ui (1.2.0.v201005250945) "Data UI Plugin" [Starting]
        org.eclipse.datatools.sqltools.db.derby (1.0.0.v200906020900) "Eclipse Data Tools Platform Derby SQL Tools Plug-in" [Active]
        org.eclipse.datatools.sqltools.db.derby.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform Derby SQL Tools UI Plug-in" [Active]
        org.eclipse.datatools.sqltools.db.generic (1.0.0.v200906020900) "Eclipse Data Tools Platform SQL Tools Generic Database Plug-in" [Active]
        org.eclipse.datatools.sqltools.db.generic.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform SQL Tools Generic Database UI Plug-in" [Active]
        org.eclipse.datatools.sqltools.ddlgen.ui (1.0.1.v201002270530) "Eclipse Data Tools Platform FE UI Plug-in" [Starting]
        org.eclipse.datatools.sqltools.debugger.core (1.0.1.v201005250945) "Eclipse Data Tools Platform SQL Debugger Framework" [Active]
        org.eclipse.datatools.sqltools.debugger.core.ui (1.0.0.v201003161000) "Eclipse Data Tools Platform SQL Debugger UI Framework" [Active]
        org.eclipse.datatools.sqltools.doc.user (1.7.0.20090521092446) "Data Tools Platform SQL Tools User Documentation" [Starting]
        org.eclipse.datatools.sqltools.doc.user.contexts (1.7.0.20090521092446) "Data Tools Platform SQL Tools User Documentation for context-sensitive help" [Starting]
        org.eclipse.datatools.sqltools.editor.core (1.0.0.v201001150815) "Eclipse Data Tools Platform SQL Editor Core Plug-in" [Active]
        org.eclipse.datatools.sqltools.editor.core.ui (1.0.0.v201001150815) "Eclipse Data Tools Platform SQL Editor Core UI Plug-in" [Active]
        org.eclipse.datatools.sqltools.parsers.sql (1.0.2.v201004291415) "Eclipse Data Tools Platform SQL Parser Plugin" [Starting]
        org.eclipse.datatools.sqltools.parsers.sql.lexer (1.0.1.v200906030654) "Eclipse Data Tools Platform Lexer Plug-in" [Starting]
        org.eclipse.datatools.sqltools.parsers.sql.query (1.2.0.v201004291415) "Eclipse Data Tools Platform SQL Query Parser Plugin" [Starting]
        org.eclipse.datatools.sqltools.parsers.sql.xml.query (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL XML Query Parser Plugin" [Starting]
        org.eclipse.datatools.sqltools.plan (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL Execution Plan View Plug-in" [Starting]
        org.eclipse.datatools.sqltools.result (1.1.0.v201005260930) "Eclipse Data Tools Platform SQL Results View Plug-ins" [Starting]
        org.eclipse.datatools.sqltools.result.ui (1.1.1.v201101140400) "Eclipse Data Tools Platform SQL Results View UI Plug-in" [Starting]
        org.eclipse.datatools.sqltools.routineeditor (1.0.0.v201003161000) "Eclipse Data Tools Platform SQL Tools Routine Editor Plug-in" [Starting]
        org.eclipse.datatools.sqltools.routineeditor.ui (1.0.1.v201004060545) "Eclipse Data Tools Platform SQL Tools Routine Editor UI Plug-in" [Starting]
        org.eclipse.datatools.sqltools.schemaobjecteditor (1.1.0.v200906022302) "Schema Object Editor Plug-in" [Starting]
        org.eclipse.datatools.sqltools.schemaobjecteditor.ui (1.1.1.200810071) "Schema Object Editor Framework" [Starting]
        org.eclipse.datatools.sqltools.schemaobjecteditor.ui.pages (1.1.0.200810071) "Schema Object Editor Pages Plug-in" [Starting]
        org.eclipse.datatools.sqltools.sql (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL Core Plug-in" [Active]
        org.eclipse.datatools.sqltools.sql.ui (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL Core UI Plug-in" [Starting]
        org.eclipse.datatools.sqltools.sqlbuilder (1.0.3.v201009131745) "SQL Builder" [Starting]
        org.eclipse.datatools.sqltools.sqleditor (1.0.2.v201009230800) "Eclipse Data Tools Platform SQL Editor" [Active]
        org.eclipse.datatools.sqltools.sqlscrapbook (1.0.1.v201005250945) "Eclipse Data Tools Platform Sqlscrapbook Plug-in" [Active]
        org.eclipse.datatools.sqltools.tabledataeditor (1.0.1.v201005250945) "Eclipse Data Tools Platform Table Data Editor Plug-in" [Starting]
        org.eclipse.debug.core (3.6.0.v20100519) "Debug Core" [Active]
        org.eclipse.debug.ui (3.6.3.v20101201_r362) "Debug UI" [Active]
        org.eclipse.draw2d (3.6.2.v20110128-0100) "Graphical Editing Framework Draw2d" [Active]
        org.eclipse.dstore.core (3.2.2.R32x_v201102121806) "RSE DStore Core" [Starting]
        org.eclipse.dstore.extra (2.1.101.v200907301400) "RSE DStore Platform Support" [Starting]
        org.eclipse.ecf (3.1.0.v20100906-1425) "ECF Core API" [Active]
        org.eclipse.ecf.filetransfer (4.0.0.v20100906-1425) "ECF Filetransfer API" [Active]
        org.eclipse.ecf.identity (3.1.0.v20100906-1425) "ECF Identity API" [Active]
        org.eclipse.ecf.provider.filetransfer (3.1.0.v20100906-1425) "ECF Filetransfer Provider" [Active]
        org.eclipse.ecf.provider.filetransfer.httpclient (4.0.0.v20100906-1425) "ECF HttpClient Filetransfer Provider" [Active]
        org.eclipse.ecf.provider.filetransfer.httpclient.ssl (1.0.0.v20100906-1425) "ECF Filetransfer Httpclient SSL Fragment" [Resolved]
        org.eclipse.ecf.provider.filetransfer.ssl (1.0.0.v20100906-1425) "ECF Filetransfer SSL Fragment" [Resolved]
        org.eclipse.ecf.ssl (1.0.100.v20100906-1425) "ECF SSL Fragment" [Resolved]
        org.eclipse.egit (0.12.1) "Git Team Provider (Incubation)" [Starting]
        org.eclipse.egit.core (0.12.1) "Git Team Provider Core (Incubation)" [Active]
        org.eclipse.egit.doc (0.12.1) "Git Team Provider Documentation (Incubation)" [Resolved]
        org.eclipse.egit.ui (0.12.1) "Git Team Provider UI (Incubation)" [Active]
        org.eclipse.emf (2.6.0.v20100914-1218) "EMF - Eclipse Modeling Framework Runtime and Tools" [Starting]
        org.eclipse.emf.ant (2.6.1.v20100905-1631) "EMF Ant Tasks" [Starting]
        org.eclipse.emf.codegen (2.6.0.v20100914-1218) "EMF Code Generation" [Starting]
        org.eclipse.emf.codegen.ecore (2.6.1.v20100914-1218) "EMF Ecore Code Generator" [Starting]
        org.eclipse.emf.codegen.ecore.ui (2.6.0.v20100914-1218) "EMF Ecore Code Generator UI" [Starting]
        org.eclipse.emf.codegen.ui (2.6.0.v20100914-1218) "EMF Code Generation UI" [Starting]
        org.eclipse.emf.common (2.6.0.v20100914-1218) "EMF Common" [Active]
        org.eclipse.emf.common.ui (2.6.0.v20100914-1218) "EMF Common UI" [Starting]
        org.eclipse.emf.converter (2.5.0.v20100914-1218) "EMF Model Converter" [Starting]
        org.eclipse.emf.databinding (1.2.0.v20100914-1218) "EMF Data Binding" [Starting]
        org.eclipse.emf.databinding.edit (1.2.0.v20100914-1218) "EMF Edit Data Binding" [Starting]
        org.eclipse.emf.ecore (2.6.1.v20100914-1218) "EMF Ecore" [Active]
        org.eclipse.emf.ecore.change (2.5.1.v20100907-1643) "EMF Change Model" [Starting]
        org.eclipse.emf.ecore.change.edit (2.5.0.v20100521-1846) "EMF Change Edit" [Starting]
        org.eclipse.emf.ecore.edit (2.6.0.v20100914-1218) "EMF Ecore Edit" [Starting]
        org.eclipse.emf.ecore.editor (2.6.0.v20100914-1218) "EMF Sample Ecore Editor" [Starting]
        org.eclipse.emf.ecore.xmi (2.5.0.v20100521-1846) "EMF XML/XMI Persistence" [Active]
        org.eclipse.emf.edit (2.6.0.v20100914-1218) "EMF Edit" [Active]
        org.eclipse.emf.edit.ui (2.6.0.v20100914-1218) "EMF Edit UI" [Starting]
        org.eclipse.emf.exporter (2.6.0.v20100521-1846) "EMF Model Exporter" [Starting]
        org.eclipse.emf.importer (2.6.0.v20100521-1846) "EMF Model Importer" [Starting]
        org.eclipse.emf.importer.ecore (2.6.0.v20100521-1846) "EMF Ecore Importer" [Starting]
        org.eclipse.emf.importer.java (2.6.0.v20100521-1846) "EMF Annotated Java Importer" [Starting]
        org.eclipse.emf.importer.rose (2.6.0.v20100521-1846) "EMF Rose Importer" [Starting]
        org.eclipse.emf.mapping (2.6.0.v20100914-1218) "EMF Mapping" [Starting]
        org.eclipse.emf.mapping.ecore (2.6.0.v20100914-1218) "EMF Ecore Mapping" [Starting]
        org.eclipse.emf.mapping.ecore.editor (2.6.0.v20100914-1218) "EMF Ecore Mapping Editor" [Starting]
        org.eclipse.emf.mapping.ecore2ecore (2.5.0.v20100521-1847) "EMF Ecore to Ecore Mapping" [Starting]
        org.eclipse.emf.mapping.ecore2ecore.editor (2.4.0.v20100521-1847) "EMF Ecore to Ecore Mapping Editor" [Starting]
        org.eclipse.emf.mapping.ecore2xml (2.5.0.v20100521-1847) "EMF Ecore to XML Mapping" [Starting]
        org.eclipse.emf.mapping.ecore2xml.ui (2.5.0.v20100521-1847) "EMF Ecore to XML Mapping Editor" [Starting]
        org.eclipse.emf.mapping.ui (2.6.0.v20100914-1218) "EMF Mapping UI" [Starting]
        org.eclipse.equinox.app (1.3.1.R36x_v20100803) "Equinox Application Container" [Active]
        org.eclipse.equinox.common (3.6.0.v20100503) "Common Eclipse Runtime" [Active]
        org.eclipse.equinox.concurrent (1.0.100.v20100503) "Equinox Concurrent API" [Starting]
        org.eclipse.equinox.ds (1.2.1.R36x_v20100803) "Declarative Services" [Active]
        org.eclipse.equinox.event (1.2.0.v20100503) "Event Admin" [Starting]
        org.eclipse.equinox.frameworkadmin (2.0.0.v20100503) "Equinox Framework Admin" [Active]
        org.eclipse.equinox.frameworkadmin.equinox (1.0.200.v20100505) "Equinox Framework Admin for Equinox" [Starting]
        org.eclipse.equinox.http.jetty (2.0.0.v20100503) "Jetty Http Service" [Active]
        org.eclipse.equinox.http.registry (1.1.1.R36x_v20101103) "Http Service Registry Extensions" [Active]
        org.eclipse.equinox.http.servlet (1.1.0.v20100503) "Http Services Servlet" [Active]
        org.eclipse.equinox.jsp.jasper (1.0.201.R36x_v20101103) "Jasper Jsp Support Bundle" [Starting]
        org.eclipse.equinox.jsp.jasper.registry (1.0.200.v20100503) "Jasper Jsp Registry Support Plug-in" [Starting]
        org.eclipse.equinox.launcher (1.1.1.R36x_v20101122_1400) "Equinox Launcher" [Resolved]
        org.eclipse.equinox.launcher.gtk.linux.x86 (1.1.2.R36x_v20101019_1345) "Equinox Launcher Linux X86 Fragment" [Resolved]
        org.eclipse.equinox.p2.artifact.repository (1.1.1.R36x_v20100901) "Equinox Provisioning Artifact Repository Support" [Active]
        org.eclipse.equinox.p2.console (1.0.200.v20100601) "Equinox Provisioning Console" [Starting]
        org.eclipse.equinox.p2.core (2.0.3.R36x_v20110111) "Equinox Provisioning Core" [Active]
        org.eclipse.equinox.p2.director (2.0.3.R36x_v20101117-1018) "Equinox Provisioning Director" [Active]
        org.eclipse.equinox.p2.director.app (1.0.201.R36x_v20100823) "Equinox Provisioning Director Application" [Starting]
        org.eclipse.equinox.p2.directorywatcher (1.0.203.R36x_v20101220) "Equinox Provisioning Directory Watcher" [Active]
        org.eclipse.equinox.p2.engine (2.0.1.R36x_v20110201) "Equinox Provisioning Engine" [Active]
        org.eclipse.equinox.p2.extensionlocation (1.2.0.v20100518) "Extension Location Repository Support" [Active]
        org.eclipse.equinox.p2.garbagecollector (1.0.100.v20100503) "Provisioning Garbage Collector" [Active]
        org.eclipse.equinox.p2.jarprocessor (1.0.200.v20100503a) "Equinox Provisioning JAR Processor" [Resolved]
        org.eclipse.equinox.p2.metadata (2.0.1.R36x_v20101202) "Equinox Provisioning Metadata" [Active]
        org.eclipse.equinox.p2.metadata.generator (1.0.202.R36x_v20101208-1400) "Equinox Provisioning Metadata Generator" [Starting]
        org.eclipse.equinox.p2.metadata.repository (1.1.0.v20100513) "Equinox Provisioning Metadata Repository" [Active]
        org.eclipse.equinox.p2.operations (2.0.0.v20100510) "Equinox Provisioning Update Checker" [Active]
        org.eclipse.equinox.p2.publisher (1.1.2.v20100824-2220) "Equinox Provisioning Publisher" [Active]
        org.eclipse.equinox.p2.ql (2.0.0.v20100503a) "p2 query language" [Starting]
        org.eclipse.equinox.p2.reconciler.dropins (1.1.2.R36x_v20110114) "Dropin Reconciler Plug-in" [Active]
        org.eclipse.equinox.p2.repository (2.0.2.R36x_v20110111-1500) "Equinox Provisioning Repository" [Active]
        org.eclipse.equinox.p2.repository.tools (2.0.1.R36x_v20100823) "Equinox p2 repository tools." [Starting]
        org.eclipse.equinox.p2.touchpoint.eclipse (2.0.3.R36x_v20101202) "Equinox Provisioning Eclipse Touchpoint" [Active]
        org.eclipse.equinox.p2.touchpoint.natives (1.0.201.R36x_v20110111) "Equinox Provisioning Native Touchpoint" [Starting]
        org.eclipse.equinox.p2.ui (2.0.0.v20100518) "Equinox Provisioning UI Support" [Active]
        org.eclipse.equinox.p2.ui.sdk (1.0.100.v20100513) "Equinox Provisioning Platform Update Support" [Active]
        org.eclipse.equinox.p2.ui.sdk.scheduler (1.0.0.v20100507-1815) "Equinox Provisioning Platform Automatic Update Support" [Active]
        org.eclipse.equinox.p2.updatechecker (1.1.101.R36x_v20100823) "Equinox Provisioning Update Checker" [Active]
        org.eclipse.equinox.p2.updatesite (1.0.201.R36x_v20100823) "Update site repository adapter bundle (Incubation)" [Starting]
        org.eclipse.equinox.preferences (3.3.0.v20100503) "Eclipse Preferences Mechanism" [Active]
        org.eclipse.equinox.registry (3.5.0.v20100503) "Extension Registry Support" [Active]
        org.eclipse.equinox.security (1.0.200.v20100503) "Equinox Java Authentication and Authorization Service (JAAS)" [Active]
        org.eclipse.equinox.security.ui (1.0.200.v20100503) "Equinox Security Default UI" [Active]
        org.eclipse.equinox.simpleconfigurator (1.0.200.v20100503) "Simple Configurator" [Active]
        org.eclipse.equinox.simpleconfigurator.manipulator (2.0.0.v20100503) "Simple Configurator Manipulator" [Active]
        org.eclipse.equinox.util (1.0.200.v20100503) "Equinox Util Bundle" [Active]
        org.eclipse.equinox.weaving.aspectj (1.0.0.v20100108) "WeavingService Plug-in (Incubation)" [Active]
        org.eclipse.equinox.weaving.caching (1.0.0.v20100108) "Standard Caching Service for Equinox Aspects (Incubation)" [Active]
        org.eclipse.equinox.weaving.caching.j9 (1.0.0.v20100108) "J9 CachingService Plug-in (Incubation)" [Active]
        org.eclipse.equinox.weaving.hook (1.0.0.v20100108) "Aspect Weaving Hooks Plug-in (Incubation)" [Resolved]
        org.eclipse.gef (3.6.2.v20110110-2020) "Graphical Editing Framework GEF" [Active]
        org.eclipse.help (3.5.0.v20100524) "Help System Core" [Active]
        org.eclipse.help.appserver (3.1.400.v20100427) "Help Application Server" [Starting]
        org.eclipse.help.base (3.5.3.v201102101200) "Help System Base" [Active]
        org.eclipse.help.ui (3.5.3.r36_20101116) "Help System UI" [Active]
        org.eclipse.help.webapp (3.5.3.r36_20101130) "Help System Webapp" [Starting]
        org.eclipse.jdt (3.6.1.v201102101200) "Eclipse Java Development Tools" [Resolved]
        org.eclipse.jdt.apt.core (3.3.402.R36_v20110120-1000) "Java Annotation Processing Core" [Active]
        org.eclipse.jdt.apt.pluggable.core (1.0.301.R36_v20100727-0110) "Java Compiler Apt IDE" [Active]
        org.eclipse.jdt.apt.ui (3.3.300.v20100513-0845) "Java Annotation Processing UI" [Starting]
        org.eclipse.jdt.compiler.apt (1.0.300.v20100513-0845) "Java Compiler Apt" [Resolved]
        org.eclipse.jdt.compiler.tool (1.0.100.v_A76_R36x) "Java Compiler Tool Support" [Resolved]
        org.eclipse.jdt.core (3.6.2.xx-20110602-1000-e36) "Java Development Tools Core" [Active]
        org.eclipse.jdt.core.manipulation (1.3.0.v20100520-0800) "Java Code Manipulation Functionality" [Active]
        org.eclipse.jdt.debug (3.6.1.v20100715_r361) "JDI Debug Model" [Active]
        org.eclipse.jdt.debug.ui (3.5.2.v20100928a_r362) "JDI Debug UI" [Active]
        org.eclipse.jdt.doc.user (3.6.1.r361_v20100721-0800) "Eclipse Java development user guide" [Resolved]
        org.eclipse.jdt.groovy.core (2.5.1.xx-20110602-1000-e36) "Eclipse-Groovy Integration Plug-in" [Active]
        org.eclipse.jdt.junit (3.6.1.r361_v20100825-0800) "Java Development Tools JUnit support" [Active]
        org.eclipse.jdt.junit.core (3.6.1.r361_v20100825-0800) "Java Development Tools JUnit core support" [Active]
        org.eclipse.jdt.junit.runtime (3.4.200.v20100526-0800) "Java Development Tools JUnit Runtime Support" [Resolved]
        org.eclipse.jdt.junit4.runtime (1.1.100.v20100526-0800) "Java Development Tools JUnit4 Runtime Support" [Resolved]
        org.eclipse.jdt.launching (3.5.200.v20110105_r362) "Java Development Tools Launching Support" [Active]
        org.eclipse.jdt.ui (3.6.2.r362_v20110203) "Java Development Tools UI" [Active]
        org.eclipse.jem (2.0.400.v201005110200) "Java EMF Model" [Active]
        org.eclipse.jem.beaninfo (2.0.300.v200905030615) "Java EMF Model BeanInfo (Introspection) Support" [Starting]
        org.eclipse.jem.beaninfo.vm (2.0.300.v201004110600) "JEM Beaninfo VM Jar" [Resolved]
        org.eclipse.jem.beaninfo.vm.common (2.0.300.v201004110600) "JEM Beaninfo Common Jar" [Resolved]
        org.eclipse.jem.proxy (2.0.301.v201101101700) "Java EMF Model Proxy Support" [Starting]
        org.eclipse.jem.util (2.1.3.v201012070000) "Java EMF Model Utilities" [Active]
        org.eclipse.jem.workbench (2.0.300.v200910290230) "Java EMF Model Workbench Support" [Active]
        org.eclipse.jface (3.6.2.M20110210-1200) "JFace" [Active]
        org.eclipse.jface.databinding (1.4.0.I20100601-0800) "JFace Data Binding for SWT and JFace" [Resolved]
        org.eclipse.jface.text (3.6.1.r361_v20100825-0800) "JFace Text" [Resolved]
        org.eclipse.jgit (0.12.1) "JGit Core (Incubation)" [Active]
        org.eclipse.jpt.branding (2.3.2.v201008242310) "Dali Java Persistence Tools" [Resolved]
        org.eclipse.jpt.core (2.3.3.v201102172310) "Dali Java Persistence Tools - Core" [Starting]
        org.eclipse.jpt.db (1.2.202.v201010192330) "Dali Java Persistence Tools - DB" [Starting]
        org.eclipse.jpt.db.ui (1.1.200.v201003290000) "Dali Java Persistence Tools - DB UI" [Resolved]
        org.eclipse.jpt.doc.user (1.3.1.v201007142310) "Dali Java Persistence Tools - Documentation" [Resolved]
        org.eclipse.jpt.eclipselink.branding (2.3.2.v201008242310) "Dali Java Persistence Tools - EclipseLink Support" [Resolved]
        org.eclipse.jpt.eclipselink.core (1.3.2.v201102072310) "Dali Java Persistence Tools - EclipseLink Support - Core" [Starting]
        org.eclipse.jpt.eclipselink.core.ddlgen (1.0.300.v201003290000) "Dali Java Persistence Tools - EclipseLink Support - DDL Generation" [Resolved]
        org.eclipse.jpt.eclipselink.jaxb.core.schemagen (1.0.0.v201005120000) "Dali Java Persistence Tools - EclipseLink JAXB Support - Schema Generation" [Resolved]
        org.eclipse.jpt.eclipselink.ui (1.3.0.v201004280001) "Dali Java Persistence Tools - EclipseLink Support - UI" [Starting]
        org.eclipse.jpt.gen (1.3.100.v201004260000) "Dali Java Persistence Tools - Entity Gen" [Resolved]
        org.eclipse.jpt.jaxb.core.schemagen (1.0.1.v201006300000) "Dali Java Persistence Tools - JAXB Support - Schema Generation" [Resolved]
        org.eclipse.jpt.jaxb.ui (1.0.1.v201006300000) "Dali Java Persistence Tools - JAXB Support - UI" [Starting]
        org.eclipse.jpt.ui (2.3.2.v201008252310) "Dali Java Persistence Tools - UI" [Starting]
        org.eclipse.jpt.utility (1.5.0.v201005100000) "Dali Java Persistence Tools - Utility" [Resolved]
        org.eclipse.jsch.core (1.1.200.I20100505-1245) "JSch Core" [Active]
        org.eclipse.jsch.ui (1.1.300.I20100505-1245) "JSch UI" [Starting]
        org.eclipse.jsf.branding (3.2.0.v20100522) "JavaServer Faces Tools" [Resolved]
        org.eclipse.jst.common.annotations.controller (1.1.300.v200908252030) "Annotation Controller Plug-in" [Resolved]
        org.eclipse.jst.common.annotations.core (1.1.300.v201004141630) "Annotation Core Plug-in" [Resolved]
        org.eclipse.jst.common.annotations.ui (1.1.300.v201002081900) "Annotations UI Plug-in" [Starting]
        org.eclipse.jst.common.frameworks (1.1.403.v201012160000) "Integration Plug-in" [Active]
        org.eclipse.jst.common.project.facet.core (1.4.102.v201008182136) "Eclipse Faceted Project Framework JDT Enablement" [Active]
        org.eclipse.jst.common.project.facet.ui (1.4.102.v201008182136) "Eclipse Faceted Project Framework JDT Enablement UI" [Starting]
        org.eclipse.jst.common.ui (1.0.3.v201101101700) "Common JST UI Plug-in" [Starting]
        org.eclipse.jst.ejb.doc.user (1.1.200.v20100519) "EJB docs" [Starting]
        org.eclipse.jst.ejb.ui (1.1.502.v201101121843) "WTP EJB UI Plug-in" [Starting]
        org.eclipse.jst.ejb.ui.infopop (1.0.300.v2010022311013) "EJB infopop" [Starting]
        org.eclipse.jst.j2ee (1.1.404.v201102081800) "Java EE Component" [Active]
        org.eclipse.jst.j2ee.core (1.2.4.v201102101900) "J2EE Core Component" [Active]
        org.eclipse.jst.j2ee.doc.user (1.1.300.v201007141655) "J2EE tools documentation" [Resolved]
        org.eclipse.jst.j2ee.ejb (1.1.402.v201102071010) "EJB component Plug-in" [Starting]
        org.eclipse.jst.j2ee.ejb.annotation.model (1.1.300.v201003112036) "EJB Annotation Model Plug-in" [Starting]
        org.eclipse.jst.j2ee.ejb.annotations.emitter (1.1.200.v200909290826) "EJB Emitter Plug-in" [Starting]
        org.eclipse.jst.j2ee.ejb.annotations.ui (1.1.200.v201004290730) "EJB Annotations Ui Plug-in" [Starting]
        org.eclipse.jst.j2ee.ejb.annotations.xdoclet (1.2.100.v201003112036) "Xdoclet Annotations Plug-in" [Starting]
        org.eclipse.jst.j2ee.infopop (1.0.300.v200805140415) "J2EE tools infopops" [Resolved]
        org.eclipse.jst.j2ee.jca (1.1.400.v201005270700) "JCA Plug-in" [Starting]
        org.eclipse.jst.j2ee.jca.ui (1.1.400.v201004150700) "WTP JCA UI Plug-in" [Starting]
        org.eclipse.jst.j2ee.navigator.ui (1.1.403.v201012020600) "J2EE Extensions to Common Navigator" [Starting]
        org.eclipse.jst.j2ee.ui (1.1.404.v201101122300) "WTP J2EE UI Plug-in" [Active]
        org.eclipse.jst.j2ee.web (1.1.404.v201102030400) "Web Plug-in" [Active]
        org.eclipse.jst.j2ee.webservice (1.1.400.v201004110600) "Web Service Plug-in" [Starting]
        org.eclipse.jst.j2ee.webservice.ui (1.1.400.v201004110600) "WTP Webservice UI Plug-in" [Starting]
        org.eclipse.jst.j2ee.xdoclet.runtime (1.1.300.v201004280700) "XDocletRuntime Plug-in" [Starting]
        org.eclipse.jst.jee (1.0.302.v201101122300) "Java EE common Plug-in" [Active]
        org.eclipse.jst.jee.ejb (1.0.301.v201007070821) "Java EE Ejb Plug-in" [Starting]
        org.eclipse.jst.jee.ui (1.0.304.v201101272100) "Eclipse Java EE Developer Tools" [Starting]
        org.eclipse.jst.jee.web (1.0.301.v201007070907) "Java EE Web Plug-in" [Starting]
        org.eclipse.jst.jsf.apache.trinidad.tagsupport (1.1.101.v20100906) "JavaServer Faces Tools - Taglibrary Metadata (Apache Trinidad)" [Starting]
        org.eclipse.jst.jsf.common (1.2.2.v201101211220) "JavaServer Faces Tools - Common" [Active]
        org.eclipse.jst.jsf.common.runtime (1.1.0.v20100510) "JavaServer Faces Tools - Common Runtime" [Starting]
        org.eclipse.jst.jsf.common.ui (1.2.0.v20100329) "JavaServer Faces Tools - Common UI" [Starting]
        org.eclipse.jst.jsf.core (1.3.3.v201102021253) "JavaServer Faces Tools - Core" [Active]
        org.eclipse.jst.jsf.doc.user (1.2.1.v20100827) "JavaServer Faces Tools - User Guide" [Starting]
        org.eclipse.jst.jsf.facelet.core (1.0.2.v201101042130) "JSF Facelets Tools - WTP Incubator Project" [Starting]
        org.eclipse.jst.jsf.facelet.ui (1.0.0.v20100602) "UI Plug-in" [Starting]
        org.eclipse.jst.jsf.facesconfig (1.2.1.v20100906) "JavaServer Faces Tools - FacesConfig Model" [Starting]
        org.eclipse.jst.jsf.facesconfig.ui (1.2.1.v201101112207) "JavaServer Faces Tools - FacesConfig Editor" [Starting]
        org.eclipse.jst.jsf.standard.tagsupport (1.2.2.v20101027) "JavaServer Faces Tools - Taglibrary Metadata" [Starting]
        org.eclipse.jst.jsf.ui (1.3.1.v20100906) "JavaServer Faces Tools - UI" [Starting]
        org.eclipse.jst.jsp.core (1.2.304.v201102160550) "Structured Source JSP Model" [Active]
        org.eclipse.jst.jsp.ui (1.1.503.v201101262228) "SSE JSP Source Editor" [Active]
        org.eclipse.jst.jsp.ui.infopop (1.0.200.v201004150328) "JSP tools infopops" [Resolved]
        org.eclipse.jst.pagedesigner (1.3.2.v201101211220) "JavaServer Faces Tools - Web Page Editor" [Starting]
        org.eclipse.jst.pagedesigner.jsf.ui (1.2.0.v20100414) "JavaServer Faces Tools - Pagedesigner UI" [Starting]
        org.eclipse.jst.pagedesigner.jsp.core (1.2.0.v20100308) "JavaServer Faces Tools - JSP Core Pagedesigner" [Starting]
        org.eclipse.jst.server.core (1.2.101.v20100421) "Java Server Support" [Active]
        org.eclipse.jst.server.generic.core (1.0.606.v20100512) "Generic Server Plugin" [Starting]
        org.eclipse.jst.server.generic.jboss (1.6.1.v200904151730) "JBoss Generic server definitions" [Starting]
        org.eclipse.jst.server.generic.jonas (1.5.205.v200805140145) "JOnAS Generic Server definitions" [Starting]
        org.eclipse.jst.server.generic.oc4j (1.5.206.v20090812) "OC4J Generic server definitions" [Starting]
        org.eclipse.jst.server.generic.ui (1.0.505.v20100428) "Generic Server Plugin UI" [Starting]
        org.eclipse.jst.server.preview.adapter (1.1.100.v20100308) "JEE Preview Server Support" [Starting]
        org.eclipse.jst.server.tomcat.core (1.1.203.v20110201) "Apache Tomcat Support" [Active]
        org.eclipse.jst.server.tomcat.ui (1.1.200.v20100418) "Apache Tomcat UI Support" [Active]
        org.eclipse.jst.server.ui (1.1.101.v20100823b) "Java Server UI Support" [Starting]
        org.eclipse.jst.server.ui.doc.user (1.0.500.v201005192218) "Server Tools documentation for J2EE Standard Tools" [Starting]
        org.eclipse.jst.server.ui.infopop (1.0.400.v200805140145) "Server Tools infopops for J2EE Standard Tools" [Resolved]
        org.eclipse.jst.server.websphere.core (1.0.302.v20080620) "WebSphere Generic Server Definition Core Plug-in" [Starting]
        org.eclipse.jst.servlet.ui (1.1.404.v201101270100) "WTP Servlet UI Plug-in" [Starting]
        org.eclipse.jst.servlet.ui.infopop (1.0.300.v200805140415) "Servlet infopop" [Starting]
        org.eclipse.jst.standard.schemas (1.1.0.v201003031644) "Java EE Related Schemas" [Resolved]
        org.eclipse.jst.ws (1.0.507.v201004211805) "Web Services" [Starting]
        org.eclipse.jst.ws.axis.consumption.core (1.0.406.v201004211805) "Web service Axis Consumption Core" [Starting]
        org.eclipse.jst.ws.axis.consumption.ui (1.0.505.v201004211805) "Webservice Axis Consumption UI" [Starting]
        org.eclipse.jst.ws.axis.creation.ui (1.0.600.v201008171516) "Webservice Axis Creation UI" [Starting]
        org.eclipse.jst.ws.axis.infopop (1.0.300.v200805140230) "Web services Axis context sensitive help" [Starting]
        org.eclipse.jst.ws.axis.ui.doc.user (1.1.100.v201005192217) "Axis Web services documentation" [Resolved]
        org.eclipse.jst.ws.axis2.consumption.core (1.0.105.v201004211805) "Webservice Axis2 Consumption Core Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.consumption.ui (1.0.103.v201004211805) "Webservice Axis2 Consumption UI Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.core (1.0.204.v201004211805) "Webservice Axis2 Core Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.creation.core (1.0.106.v201004211805) "Webservice Axis2 Creation Core Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.creation.ui (1.0.104.v201004211805) "Webservice Axis2 Creation UI Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.ui (1.0.303.v201003110431) "Axis2 Tools" [Starting]
        org.eclipse.jst.ws.axis2.ui.doc.user (1.0.100.v201005192217) "Axis2 Web services documentation" [Resolved]
        org.eclipse.jst.ws.consumption (1.0.507.v201004211805) "Web Services Consumption" [Starting]
        org.eclipse.jst.ws.consumption.infopop (1.0.300.v200805140230) "Web services UI" [Resolved]
        org.eclipse.jst.ws.consumption.ui (1.1.302.v201101191731) "Web Services Consumption Graphical User Interface" [Starting]
        org.eclipse.jst.ws.consumption.ui.doc.user (1.0.600.v201005192217) "Web service consumption documentation" [Starting]
        org.eclipse.jst.ws.creation.ejb.ui (1.0.201.v201004211805) "Web Services Creation EJB Graphical User Interface" [Resolved]
        org.eclipse.jst.ws.creation.ui (1.0.510.v201011041151) "Web Services Creation Graphical User Interface" [Starting]
        org.eclipse.jst.ws.doc.user (1.0.600.v201005192217) "Web Services UI" [Resolved]
        org.eclipse.jst.ws.infopop (1.0.300.v200805140230) "Web services UI" [Resolved]
        org.eclipse.jst.ws.jaxrs.core (1.0.201.v201011231540) "JAX-RS Tools - Core" [Active]
        org.eclipse.jst.ws.jaxrs.ui (1.0.301.v201012020511) "JAX-RS Tools - UI" [Starting]
        org.eclipse.jst.ws.uddiregistry (1.0.500.v201004211805) "Web Services Universal Description Discovery and Integration Registry" [Starting]
        org.eclipse.jst.ws.ui (1.0.403.v201004211805) "Web Services Graphical User Interface" [Starting]
        org.eclipse.ltk.core.refactoring (3.5.101.r362_v20101117-0800) "Refactoring Core" [Active]
        org.eclipse.ltk.ui.refactoring (3.5.0.v20100526-0800) "Refactoring UI" [Active]
        org.eclipse.mylyn (3.5.0.v20110316-0100) "Mylyn" [Resolved]
        org.eclipse.mylyn.bugzilla.core (3.5.0.v20110316-0100) "Mylyn Bugzilla Connector Core" [Active]
        org.eclipse.mylyn.bugzilla.ide (3.5.0.v20110316-0100) "Mylyn Bugzilla IDE Extensions" [Resolved]
        org.eclipse.mylyn.bugzilla.ui (3.5.0.v20110316-0100) "Mylyn Bugzilla Connector UI" [Active]
        org.eclipse.mylyn.commons.core (3.5.0.v20110316-0100) "Mylyn Commons Core" [Resolved]
        org.eclipse.mylyn.commons.net (3.5.0.v20110316-0100) "Mylyn Commons Net" [Active]
        org.eclipse.mylyn.commons.repositories (0.1.0.v20110316-0100) "Mylyn Commons" [Resolved]
        org.eclipse.mylyn.commons.screenshots (1.0.0.v20110316-0100) "Mylyn Commons" [Resolved]
        org.eclipse.mylyn.commons.soap (3.5.0.v20110316-0100) "Mylyn Commons Soap" [Resolved]
        org.eclipse.mylyn.commons.team (0.1.0.v20110316-0100) "Mylyn Commons" [Starting]
        org.eclipse.mylyn.commons.ui (3.5.0.v20110316-0100) "Mylyn Commons UI" [Active]
        org.eclipse.mylyn.commons.xmlrpc (3.5.0.v20110316-0100) "Mylyn XML-RPC Support" [Starting]
        org.eclipse.mylyn.context.core (3.5.0.v20110316-0100) "Mylyn Context Core" [Active]
        org.eclipse.mylyn.context.ui (3.5.0.v20110316-0100) "Mylyn Context UI" [Active]
        org.eclipse.mylyn.discovery.core (3.5.0.v20110316-0100) "Mylyn Connector Discovery Core" [Resolved]
        org.eclipse.mylyn.discovery.ui (3.5.0.v20110316-0100) "Mylyn Connector Discovery UI" [Resolved]
        org.eclipse.mylyn.help.ui (3.5.0.v20110316-0100) "Mylyn Help" [Starting]
        org.eclipse.mylyn.ide.ant (3.5.0.v20110316-0100) "Mylyn Ant Bridge" [Active]
        org.eclipse.mylyn.ide.ui (3.5.0.v20110316-0100) "Mylyn IDE UI" [Active]
        org.eclipse.mylyn.java.tasks (3.5.0.v20110316-0100) "Mylyn Java Tasks" [Active]
        org.eclipse.mylyn.java.ui (3.5.0.v20110316-0100) "Mylyn Java Bridge" [Active]
        org.eclipse.mylyn.jira.core (3.4.0) "Atlassian Connector for Eclipse replacement for Mylyn Jira Connector Core" [Starting]
        org.eclipse.mylyn.jira.ui (3.4.0) "Atlassian Connector for Eclipse replacement for Mylyn JIRA Connector UI" [Starting]
        org.eclipse.mylyn.monitor.core (3.5.0.v20110316-0100) "Mylyn Monitor Core" [Resolved]
        org.eclipse.mylyn.monitor.ui (3.5.0.v20110316-0100) "Mylyn Monitor UI" [Active]
        org.eclipse.mylyn.resources.ui (3.5.0.v20110316-0100) "Mylyn Resources UI" [Active]
        org.eclipse.mylyn.tasks.bugs (3.5.0.v20110316-0100) "Mylyn Bug Reporting" [Starting]
        org.eclipse.mylyn.tasks.core (3.5.0.v20110316-0100) "Mylyn Tasks Core" [Resolved]
        org.eclipse.mylyn.tasks.search (3.5.0.v20110316-0100) "Mylyn Tasks UI" [Resolved]
        org.eclipse.mylyn.tasks.ui (3.5.0.v20110316-0100) "Mylyn Tasks UI" [Active]
        org.eclipse.mylyn.team.cvs (3.5.0.v20110316-0100) "Mylyn CVS Extensions" [Resolved]
        org.eclipse.mylyn.team.ui (3.5.0.v20110316-0100) "Mylyn Team UI" [Active]
        org.eclipse.mylyn.wikitext.confluence.core (1.4.0.v20110316-0100) "Mylyn WikiText Confluence" [Resolved]
        org.eclipse.mylyn.wikitext.confluence.ui (1.4.0.v20110316-0100) "Mylyn WikiText Confluence UI" [Resolved]
        org.eclipse.mylyn.wikitext.core (1.4.0.v20110316-0100) "Mylyn WikiText" [Active]
        org.eclipse.mylyn.wikitext.help.ui (1.4.0.v20110316-0100) "Mylyn WikiText Help UI" [Resolved]
        org.eclipse.mylyn.wikitext.mediawiki.core (1.4.0.v20110316-0100) "Mylyn WikiText MediaWiki" [Resolved]
        org.eclipse.mylyn.wikitext.mediawiki.ui (1.4.0.v20110316-0100) "Mylyn WikiText MediaWiki UI" [Resolved]
        org.eclipse.mylyn.wikitext.tasks.ui (1.4.0.v20110316-0100) "Mylyn WikiText Tasks UI" [Active]
        org.eclipse.mylyn.wikitext.textile.core (1.4.0.v20110316-0100) "Mylyn WikiText Textile" [Resolved]
        org.eclipse.mylyn.wikitext.textile.ui (1.4.0.v20110316-0100) "Mylyn WikiText Textile UI" [Resolved]
        org.eclipse.mylyn.wikitext.tracwiki.core (1.4.0.v20110316-0100) "Mylyn WikiText TracWiki" [Resolved]
        org.eclipse.mylyn.wikitext.tracwiki.ui (1.4.0.v20110316-0100) "Mylyn WikiText TracWiki UI" [Resolved]
        org.eclipse.mylyn.wikitext.twiki.core (1.4.0.v20110316-0100) "Mylyn WikiText Twiki" [Resolved]
        org.eclipse.mylyn.wikitext.twiki.ui (1.4.0.v20110316-0100) "Mylyn WikiText Twiki UI" [Resolved]
        org.eclipse.mylyn.wikitext.ui (1.4.0.v20110316-0100) "Mylyn WikiText UI" [Active]
        org.eclipse.osgi (3.6.2.R36x_v20110210) "OSGi System Bundle" [Active]
        org.eclipse.osgi.services (3.2.100.v20100503) "OSGi Release 4.2.0 Services" [Resolved]
        org.eclipse.osgi.util (3.2.100.v20100503) "OSGi Release 4.2.0 Utility Classes" [Resolved]
        org.eclipse.pde (3.6.1.v201102101200) "PDE" [Resolved]
        org.eclipse.pde.api.tools (1.0.202.v20100820_r361) "API Tools" [Active]
        org.eclipse.pde.api.tools.ui (1.0.201.v20100820_r361) "API Tools UI" [Active]
        org.eclipse.pde.build (3.6.2.R36x_20110203) "Plug-in Development Environment Build Support" [Starting]
        org.eclipse.pde.core (3.6.2.v20110210_r362) "PDE Core" [Active]
        org.eclipse.pde.doc.user (3.6.2.v20101118_r362) "PDE User Guide" [Resolved]
        org.eclipse.pde.ds.core (1.0.100.v20100601) "PDE DS Core" [Starting]
        org.eclipse.pde.ds.ui (1.0.100.v20100601) "PDE DS UI" [Starting]
        org.eclipse.pde.junit.runtime (3.4.100.v20100601) "PDE JUnit Runtime Support" [Resolved]
        org.eclipse.pde.launching (3.6.0.v20100601) "PDE Launching Support" [Active]
        org.eclipse.pde.runtime (3.4.200.v20100601) "PDE Runtime" [Starting]
        org.eclipse.pde.ua.core (1.0.100.v20100504) "PDE UA Core" [Starting]
        org.eclipse.pde.ua.ui (1.0.100.v20100504) "PDE UA UI" [Starting]
        org.eclipse.pde.ui (3.6.1.v20110210_r362) "PDE UI" [Active]
        org.eclipse.pde.ui.templates (3.4.200.v20100601) "PDE Templates" [Starting]
        org.eclipse.persistence.antlr (2.1.2.v20101206-r8635) "EclipseLink ANTLR" [Resolved]
        org.eclipse.persistence.asm (2.1.2.v20101206-r8635) "EclipseLink ASM" [Resolved]
        org.eclipse.persistence.core (2.1.2.v20101206-r8635) "EclipseLink Core" [Resolved]
        org.eclipse.persistence.jpa (2.1.2.v20101206-r8635) "EclipseLink JPA" [Resolved]
        org.eclipse.persistence.jpa.equinox (2.1.2.v20101206-r8635) "EclipseLink Dynamic Weaving Fragment for Equinox" [Resolved]
        org.eclipse.persistence.jpa.equinox.weaving (2.1.2.v20101206-r8635) "Dynamic Weaving Fragment for Equinox" [Resolved]
        org.eclipse.persistence.jpa.osgi (2.1.2.v20101206-r8635) "EclipseLink OSGi Deployment Fragment (deprectated, non Gemini)" [Resolved]
        org.eclipse.persistence.moxy (2.1.2.v20101206-r8635) "EclipseLink MOXy" [Resolved]
        org.eclipse.persistence.oracle (2.1.2.v20101206-r8635) "EclipseLink Oracle Extensions" [Resolved]
        org.eclipse.persistence.sdo (2.1.2.v20101206-r8635) "EclipseLink SDO" [Resolved]
        org.eclipse.platform (3.6.2.v201102101200) "Eclipse Platform" [Resolved]
        org.eclipse.platform.doc.user (3.6.2.r362_v20101117-0800) "Eclipse Workbench User Guide" [Resolved]
        org.eclipse.rcp (3.6.0.v201102101200) "Eclipse RCP" [Starting]
        org.eclipse.rse (3.2.2.R32x_v201102011435) "Remote System Explorer End-User Runtime" [Resolved]
        org.eclipse.rse.connectorservice.dstore (3.1.100.v201005281600) "RSE DStore Connector Service" [Starting]
        org.eclipse.rse.connectorservice.local (2.1.100.v200905272300) "RSE Local Connector Service" [Starting]
        org.eclipse.rse.connectorservice.ssh (2.1.100.v200905272300) "RSE SSH Connector Service" [Starting]
        org.eclipse.rse.connectorservice.telnet (1.2.1.v200908051630) "RSE Telnet Connector Service" [Starting]
        org.eclipse.rse.core (3.1.102.R32x_v201102011435) "RSE Core" [Starting]
        org.eclipse.rse.doc.user (3.2.2.R32x_v201102011435) "RSE User Guide" [Resolved]
        org.eclipse.rse.dstore.security (3.0.200.v201003010830) "RSE DStore SSL Support" [Starting]
        org.eclipse.rse.efs (2.1.200.v201005262000) "RSE Eclipse Filesystem (EFS) Provider" [Starting]
        org.eclipse.rse.efs.ui (2.1.200.v201003010830) "RSE Eclipse Filesystem (EFS) Provider UI Support" [Resolved]
        org.eclipse.rse.files.ui (3.1.102.R32x_v201102011435) "RSE Files UI" [Starting]
        org.eclipse.rse.importexport (1.2.101.v201008191400) "RSE Import/Export" [Starting]
        org.eclipse.rse.processes.ui (3.0.200.v201003010830) "RSE Processes UI" [Starting]
        org.eclipse.rse.services (3.2.2.R32x_v201102011435) "RSE Services Framework" [Starting]
        org.eclipse.rse.services.dstore (3.1.102.R32x_v201102011435) "RSE DStore Services" [Starting]
        org.eclipse.rse.services.files.ftp (3.0.200.v201004072040) "RSE FTP Service" [Starting]
        org.eclipse.rse.services.local (2.1.202.R32x_v201102011435) "RSE Local Services" [Starting]
        org.eclipse.rse.services.ssh (3.0.1.v200909160005) "RSE SSH Services" [Starting]
        org.eclipse.rse.services.telnet (2.0.0.v200905272300) "RSE Telnet Service" [Starting]
        org.eclipse.rse.shells.ui (3.0.200.v201006041352) "RSE Shells UI" [Starting]
        org.eclipse.rse.subsystems.files.core (3.2.1.v201008191400) "RSE Files Core" [Starting]
        org.eclipse.rse.subsystems.files.dstore (2.1.102.R32x_v201102011435) "RSE DStore Files" [Starting]
        org.eclipse.rse.subsystems.files.ftp (2.1.100.v200905272300) "RSE FTP Files" [Starting]
        org.eclipse.rse.subsystems.files.local (2.1.101.v200907301400) "RSE Local Files" [Starting]
        org.eclipse.rse.subsystems.files.ssh (2.1.100.v200905272300) "RSE SSH Files" [Starting]
        org.eclipse.rse.subsystems.processes.core (3.1.100.v201003010830) "RSE Processes Core" [Starting]
        org.eclipse.rse.subsystems.processes.dstore (2.1.100.v200905272300) "RSE DStore Processes" [Starting]
        org.eclipse.rse.subsystems.processes.local (2.1.100.v200905272300) "RSE Local Processes" [Starting]
        org.eclipse.rse.subsystems.processes.shell.linux (1.1.100.v200905272300) "RSE Linux Shell Processes" [Starting]
        org.eclipse.rse.subsystems.shells.core (3.1.100.v201003010830) "RSE Shells Core" [Starting]
        org.eclipse.rse.subsystems.shells.dstore (2.1.201.v201008191400) "RSE DStore Shells" [Starting]
        org.eclipse.rse.subsystems.shells.local (2.1.100.v200905272300) "RSE Local Shells" [Starting]
        org.eclipse.rse.subsystems.shells.ssh (2.1.100.v200905272300) "RSE SSH Shells" [Starting]
        org.eclipse.rse.subsystems.shells.telnet (1.2.0.v200905272300) "RSE Telnet Shells" [Starting]
        org.eclipse.rse.subsystems.terminals.core (1.0.100.v201006041352) "RSE Terminals Core" [Resolved]
        org.eclipse.rse.subsystems.terminals.ssh (1.0.1.v200908051630) "RSE SSH Terminals" [Starting]
        org.eclipse.rse.terminals.ui (1.0.100.v201006041352) "RSE Terminals UI" [Starting]
        org.eclipse.rse.ui (3.1.102.R32x_v201102011435) "RSE UI" [Starting]
        org.eclipse.rse.useractions (1.1.100.v200905272300) "Remote System Explorer User Actions" [Starting]
        org.eclipse.search (3.6.0.v20100520-0800) "Search Support" [Active]
        org.eclipse.swt (3.6.2.v3659c) "Standard Widget Toolkit" [Resolved]
        org.eclipse.swt.gtk.linux.x86 (3.6.2.v3659b) "Standard Widget Toolkit for GTK 2.0" [Resolved]
        org.eclipse.team.core (3.5.101.R36x_v20110203-1036) "Team Support Core" [Active]
        org.eclipse.team.cvs.core (3.3.301.R36x_v20110119-0815) "CVS Team Provider Core" [Active]
        org.eclipse.team.cvs.ssh2 (3.2.300.I20100526-0800) "CVS SSH2" [Starting]
        org.eclipse.team.cvs.ui (3.3.302.R36x_v20110203-1036) "CVS Team Provider UI" [Active]
        org.eclipse.team.svn (0.7.9.I20110318-1700) "Subversive SVN Team Provider (Incubation)" [Resolved]
        org.eclipse.team.svn.core (0.7.9.I20110523-1700) "Subversive SVN Team Provider Core Plug-in (Incubation)" [Active]
        org.eclipse.team.svn.help (0.7.9.I20110318-1700) "Subversive SVN Team Provider User Guide Plug-in (Incubation)" [Resolved]
        org.eclipse.team.svn.mylyn (0.7.9.I20110318-1700) "Subversive Integration for the Mylyn Project (Incubation)" [Active]
        org.eclipse.team.svn.resource.ignore.rules.jdt (0.7.9.I20101203-1700) "Subversive JDT Ignore Extensions (Incubation)" [Resolved]
        org.eclipse.team.svn.ui (0.7.9.I20110523-1700) "Subversive SVN Team Provider UI Plug-in (Incubation)" [Active]
        org.eclipse.team.ui (3.5.102.R36x_v20110203-1036) "Team Support UI" [Active]
        org.eclipse.text (3.5.0.v20100601-1300) "Text" [Resolved]
        org.eclipse.tm.terminal (3.0.102.R32x_v201102011435) "Target Management Terminal Widget" [Starting]
        org.eclipse.tm.terminal.ssh (2.0.200.v201005271030) "Target Management Terminal SSH Connector" [Starting]
        org.eclipse.tm.terminal.telnet (2.0.101.v200909160005) "Target Management Terminal Telnet Connector" [Resolved]
        org.eclipse.tm.terminal.view (2.1.2.R32x_v201102011435) "Target Management Terminal View" [Starting]
        org.eclipse.ui (3.6.2.M20110203-1100) "Eclipse UI" [Active]
        org.eclipse.ui.browser (3.3.1.r36_20101216) "Browser Support" [Active]
        org.eclipse.ui.cheatsheets (3.4.0.v20100427) "Cheat Sheets" [Active]
        org.eclipse.ui.console (3.5.0.v20100526) "Console" [Active]
        org.eclipse.ui.editors (3.6.1.r361_v20100825-0800) "Default Text Editor" [Active]
        org.eclipse.ui.externaltools (3.2.0.v20100427) "External Tools" [Starting]
        org.eclipse.ui.forms (3.5.2.r36_v20100702) "Eclipse Forms" [Active]
        org.eclipse.ui.ide (3.6.2.M20101201-0800) "Eclipse IDE UI" [Active]
        org.eclipse.ui.ide.application (1.0.201.M20100707-0800) "Eclipse IDE UI Application" [Resolved]
        org.eclipse.ui.intro (3.4.0.v20100427) "Welcome Framework" [Starting]
        org.eclipse.ui.intro.universal (3.2.402.r36_v20100702) "Universal Welcome" [Starting]
        org.eclipse.ui.navigator (3.5.0.I20100601-0800) "Common Navigator View" [Active]
        org.eclipse.ui.navigator.resources (3.4.202.M20101124-0800) "Navigator Workbench Components" [Active]
        org.eclipse.ui.net (1.2.100.I20100505-1245) "Internet Connection Management UI" [Active]
        org.eclipse.ui.presentations.r21 (3.2.200.I20100517-1500) "R21 Presentation Plug-in" [Starting]
        org.eclipse.ui.views (3.5.1.M20110202-0800) "Views" [Active]
        org.eclipse.ui.views.log (1.0.100.v20110210_r362) "Log View" [Active]
        org.eclipse.ui.views.properties.tabbed (3.5.100.I20100509-0800) "Tabbed Properties View" [Active]
        org.eclipse.ui.workbench (3.6.2.M20110210-1200) "Workbench" [Active]
        org.eclipse.ui.workbench.compatibility (3.2.100.I20100511-0800) "Workbench Compatibility" [Resolved]
        org.eclipse.ui.workbench.texteditor (3.6.1.r361_v20100714-0800) "Text Editor Framework" [Active]
        org.eclipse.update.configurator (3.3.100.v20100512) "Install/Update Configurator" [Active]
        org.eclipse.update.core (3.2.402.R36x_v20100629) "Install/Update Core" [Active]
        org.eclipse.update.core.linux (3.2.200.v20100512) "fragmentNameLinux" [Resolved]
        org.eclipse.update.scheduler (3.2.300.v20100512) "Automatic Updates Scheduler" [Active]
        org.eclipse.update.ui (3.2.300.v20100512) "Install/Update UI" [Starting]
        org.eclipse.wst.command.env (1.0.409.v201004211805) "Environment Command Framework (headless)" [Active]
        org.eclipse.wst.command.env.core (1.0.205.v201004211805) "Environment Command Framework (core)" [Resolved]
        org.eclipse.wst.command.env.doc.user (1.5.300.v201005192225) "Web services Axis Ant task documentation" [Starting]
        org.eclipse.wst.command.env.infopop (1.0.100.v200805301544) "Web services UI" [Starting]
        org.eclipse.wst.command.env.ui (1.1.3.v201004211805) "Environment Command Framework (GUI)" [Starting]
        org.eclipse.wst.common.core (1.2.0.v200908252030) "WST Common Core Plug-in" [Active]
        org.eclipse.wst.common.emf (1.2.3.v201012100400) "EMF Utilities" [Active]
        org.eclipse.wst.common.emfworkbench.integration (1.2.3.v201012020600) "EMF Workbench Edit Plug-in" [Active]
        org.eclipse.wst.common.environment (1.0.400.v200912181832) "Environment Plug-in" [Starting]
        org.eclipse.wst.common.frameworks (1.2.0.v201003040800) "Common Frameworks" [Active]
        org.eclipse.wst.common.frameworks.ui (1.2.0.v201004080500) "WTP UI Plug-in" [Active]
        org.eclipse.wst.common.infopop (1.0.300.v201004280700) "Common WST infopops" [Starting]
        org.eclipse.wst.common.modulecore (1.2.5.v201101270100) "Modulecore Plug-in" [Active]
        org.eclipse.wst.common.modulecore.ui (1.0.4.v201101101700) "Modulecore UI Plug-in" [Starting]
        org.eclipse.wst.common.project.facet.core (1.4.102.v201008170019) "Eclipse Faceted Project Framework" [Active]
        org.eclipse.wst.common.project.facet.ui (1.4.103.v201101271715) "Eclipse Faceted Project Framework UI" [Starting]
        org.eclipse.wst.common.snippets (1.2.2.v201101130441) "Snippets View" [Starting]
        org.eclipse.wst.common.ui (1.1.500.v200911190730) "Eclipse Base UI extensions" [Starting]
        org.eclipse.wst.common.uriresolver (1.1.401.v201004280700) "Common URI Resolver Framework" [Active]
        org.eclipse.wst.css.core (1.1.402.v201102031915) "Structured Source CSS Model" [Active]
        org.eclipse.wst.css.ui (1.0.502.v201101122002) "SSE CSS Source Editor" [Starting]
        org.eclipse.wst.doc.user (1.2.0.v200806052254) "Master User Doc TOC" [Starting]
        org.eclipse.wst.dtd.core (1.1.401.v201101122255) "Structured Source DTD Core" [Active]
        org.eclipse.wst.dtd.ui (1.0.500.v201004290328) "SSE DTD Source Editor" [Active]
        org.eclipse.wst.dtd.ui.infopop (1.0.300.v200805140200) "DTD Editor infopops" [Resolved]
        org.eclipse.wst.dtdeditor.doc.user (1.0.600.v201005192212) "DTD Editor documentation" [Resolved]
        org.eclipse.wst.html.core (1.1.404.v201101190004) "Structured Source HTML Model" [Active]
        org.eclipse.wst.html.ui (1.0.504.v201101122108) "HTML UI Source Editor" [Active]
        org.eclipse.wst.html.ui.infopop (1.0.200.v201004150328) "HTML editor infopops" [Resolved]
        org.eclipse.wst.internet.cache (1.0.400.v201004280700) "Cache URI Resolver Plug-in" [Active]
        org.eclipse.wst.internet.monitor.core (1.0.404.v20090609) "Monitor" [Starting]
        org.eclipse.wst.internet.monitor.ui (1.0.405.v20100309) "TCP/IP Monitor" [Starting]
        org.eclipse.wst.jsdt.core (1.1.4.v201102102045) "JavaScript Development Tools Core" [Active]
        org.eclipse.wst.jsdt.debug.core (1.0.3.v201011040143) "JavaScript Debug Core" [Active]
        org.eclipse.wst.jsdt.debug.rhino (1.0.1.v201008170101) "Rhino JavaScript Debug" [Starting]
        org.eclipse.wst.jsdt.debug.rhino.debugger (1.0.1.v201008170101) "Rhino Debugger" [Resolved]
        org.eclipse.wst.jsdt.debug.ui (1.0.3.v201011040143) "JavaScript Debug UI" [Active]
        org.eclipse.wst.jsdt.doc (1.0.301.v201007150153) "JSDT Doc Plugin" [Resolved]
        org.eclipse.wst.jsdt.manipulation (1.0.200.v201004150600) "JavaScript Code Manipulation Functionality" [Active]
        org.eclipse.wst.jsdt.support.firefox (1.0.300.v201004150600) "JSDT support for Mozilla FireFox" [Starting]
        org.eclipse.wst.jsdt.support.ie (1.0.300.v201004150600) "JSDT support for Microsoft Internet Explorer" [Resolved]
        org.eclipse.wst.jsdt.ui (1.1.4.v201102160540) "Eclipse JavaScript Development Tools" [Active]
        org.eclipse.wst.jsdt.web.core (1.0.304.v201102160550) "JSDT Web Support Core" [Starting]
        org.eclipse.wst.jsdt.web.support.jsp (1.0.303.v201012160047) "JSDT support for JSP Plug-in" [Starting]
        org.eclipse.wst.jsdt.web.ui (1.0.304.v201012160349) "JSDT Web Support UI" [Starting]
        org.eclipse.wst.server.core (1.1.206.v20110110) "Server Core" [Active]
        org.eclipse.wst.server.discovery (1.0.101.v20100707) "Plug-in Discovery Plug-in" [Starting]
        org.eclipse.wst.server.http.core (1.0.200.v20090429) "HTTP Server Support" [Starting]
        org.eclipse.wst.server.http.ui (1.0.200.v20090113) "HTTP Server UI Support" [Starting]
        org.eclipse.wst.server.preview (1.1.100.v20091208) "Preview Server Support" [Starting]
        org.eclipse.wst.server.preview.adapter (1.1.0.v20090311b) "HTTP Preview Support" [Starting]
        org.eclipse.wst.server.ui (1.1.207.v20110119) "Server UI" [Active]
        org.eclipse.wst.server.ui.doc.user (1.1.300.v201005192125) "Server Tools documentation for Web Standard Tools" [Starting]
        org.eclipse.wst.server.ui.infopop (1.1.100.v201005192130) "Server Tools infopops for Web Standard Tools" [Resolved]
        org.eclipse.wst.sse.core (1.1.504.v201102160550) "Structured Source Model" [Active]
        org.eclipse.wst.sse.doc.user (1.1.100.v201005192212) "Structured text editor and snippets documentation" [Resolved]
        org.eclipse.wst.sse.ui (1.2.3.v201102102045) "Structured Source Editor" [Active]
        org.eclipse.wst.sse.ui.infopop (1.0.300.v201004150328) "SSE infopops" [Resolved]
        org.eclipse.wst.standard.schemas (1.0.300.v201004110600) "Standard Schemas and DTDs" [Resolved]
        org.eclipse.wst.validation (1.2.201.v201101270100) "Validation Framework" [Active]
        org.eclipse.wst.validation.infopop (1.0.300.v200806041506) "WST validation infopop plug-in" [Resolved]
        org.eclipse.wst.validation.ui (1.2.204.v201004150700) "Validation Framework UI" [Starting]
        org.eclipse.wst.web (1.1.402.v201012160000) "Simple Web Plug-in" [Active]
        org.eclipse.wst.web.ui (1.1.400.v201004141630) "Eclipse Web Developer Tools" [Starting]
        org.eclipse.wst.web.ui.infopop (1.0.300.v200805140415) "Static Web infopop" [Starting]
        org.eclipse.wst.webtools.doc.user (1.0.500.v201005192212) "Web tools documentation" [Starting]
        org.eclipse.wst.ws (1.1.203.v201004211805) "Web Services" [Active]
        org.eclipse.wst.ws.explorer (1.0.507.v201004220342) "Web Services Explorer" [Starting]
        org.eclipse.wst.ws.infopop (1.0.300.v200805140230) "Web Services UI" [Starting]
        org.eclipse.wst.ws.parser (1.0.403.v201004211805) "Web Services Description Parser" [Starting]
        org.eclipse.wst.ws.service.policy (1.0.204.v201011011834) "Service Policy - Core" [Active]
        org.eclipse.wst.ws.service.policy.ui (1.0.202.v201004211732) "Service Policy - UI" [Active]
        org.eclipse.wst.ws.ui (1.1.200.v201004211805) "Web Services UI" [Starting]
        org.eclipse.wst.wsdl (1.2.104.v201012082239) "WSDL Model" [Starting]
        org.eclipse.wst.wsdl.ui (1.2.304.v201012071645) "WSDL UI" [Starting]
        org.eclipse.wst.wsdl.ui.doc.user (1.0.700.v201007141653) "WSDL Editor Documentation" [Starting]
        org.eclipse.wst.wsdl.validation (1.1.501.v201004201506) "WSDL Validator" [Active]
        org.eclipse.wst.wsi (1.0.400.v201004220210) "WSI Conformance Tools" [Active]
        org.eclipse.wst.wsi.ui (1.0.501.v201004201506) "Soap Monitor" [Starting]
        org.eclipse.wst.wsi.ui.doc.user (1.0.600.v201007141654) "WS-I Validation Documentation" [Resolved]
        org.eclipse.wst.xml.core (1.1.503.v201102102045) "Structured Source XML Model" [Active]
        org.eclipse.wst.xml.ui (1.1.103.v201101122108) "Eclipse XML Editors and Tools" [Active]
        org.eclipse.wst.xml.ui.infopop (1.0.400.v201004292007) "XML infopops" [Resolved]
        org.eclipse.wst.xml.xpath.core (1.1.1.v201007022358) "XPath Core" [Starting]
        org.eclipse.wst.xml.xpath.ui (1.1.2.v201101212242) "XPath UI" [Starting]
        org.eclipse.wst.xml.xpath2 (1.1.0.v200910101444) "Eclipse XPath 2 Developers Tools" [Resolved]
        org.eclipse.wst.xml.xpath2.processor (1.1.4.v201101212357) "PsychoPath XPath 2.0 Processor" [Starting]
        org.eclipse.wst.xml.xpath2.processor.doc.user (1.0.0.v201005240426) "XPath 2.0 (PsychoPath) User Documentation" [Resolved]
        org.eclipse.wst.xmleditor.doc.user (1.0.700.v201005192212) "XML editor" [Resolved]
        org.eclipse.wst.xsd.core (1.1.503.v201011121919) "XSD Core Plugin" [Active]
        org.eclipse.wst.xsd.ui (1.2.304.v201101251958) "XML Schema Editor" [Starting]
        org.eclipse.wst.xsdeditor.doc.user (1.0.800.v201005192212) "XML schema editor" [Resolved]
        org.eclipse.wst.xsl (1.0.0.v200905250058) "Eclipse XSL Developer Tools" [Resolved]
        org.eclipse.wst.xsl.core (1.1.0.v201004290328) "XSL Core" [Active]
        org.eclipse.wst.xsl.debug.ui (1.0.101.v201102111830) "XSL Debugger UI" [Active]
        org.eclipse.wst.xsl.doc (1.0.100.v201004292007) "XSL User Documentation (Incubating)" [Resolved]
        org.eclipse.wst.xsl.exslt.core (1.0.0.v201005240426) "EXSLT UI Extensions" [Active]
        org.eclipse.wst.xsl.exslt.ui (1.0.0.v201006012005) "EXSLT Core Extensions" [Starting]
        org.eclipse.wst.xsl.jaxp.debug (1.0.100.v201004290328) "XSL JAXP Debugger" [Resolved]
        org.eclipse.wst.xsl.jaxp.debug.ui (1.0.100.v201004290328) "XSL JAXP Debug UI" [Starting]
        org.eclipse.wst.xsl.jaxp.launching (1.0.100.v201004290328) "XSL JAXP Launching" [Starting]
        org.eclipse.wst.xsl.launching (1.0.100.v201004290328) "XSL Transform Launching" [Starting]
        org.eclipse.wst.xsl.saxon (1.0.100.v201004290328) "XSL Saxon Support" [Resolved]
        org.eclipse.wst.xsl.ui (1.1.1.v201009091745) "XSL Editor and Validation" [Active]
        org.eclipse.wst.xsl.xalan (1.0.1.v201004290328) "XSL Xalan Support" [Resolved]
        org.eclipse.xsd (2.6.0.v20100914-1218) "XSD Model" [Active]
        org.eclipse.xsd.edit (2.6.0.v20100914-1218) "XSD Edit" [Starting]
        org.eclipse.zest.core (1.2.0.v20101209-2020) "Graphical Editing Framework Zest Core" [Resolved]
        org.eclipse.zest.layouts (1.1.0.v20101209-2020) "Graphical Editing Framework Zest Layouts" [Resolved]
        org.h2 (1.1.117.v20091003-1000) "H2 Database Engine" [Resolved]
        org.hamcrest.core (1.1.0.v20090501071000) "Hamcrest Core Library of Matchers" [Starting]
        org.jdom (1.0.0.v201005080400) "JDOM" [Resolved]
        org.junit (3.8.2.v3_8_2_v20100427-1100) "JUnit Testing Framework" [Resolved]
        org.junit (4.8.1.v4_8_1_v20100427-1100) "JUnit Testing Framework" [Resolved]
        org.junit4 (4.8.1.v20100525) "JUnit Testing Framework Version 4" [Resolved]
        org.maven.ide.eclipse (0.12.1.20110112-1712) "Maven Integration for Eclipse" [Active]
        org.maven.ide.eclipse.ajdt (0.10.0.20100209-0800) "Maven Integration for Eclipse AJDT" [Resolved]
        org.maven.ide.eclipse.archetype_common (0.12.1.20110112-1712) "Maven Archetype Common Bundle" [Resolved]
        org.maven.ide.eclipse.dependency_tree (0.12.1.20110112-1712) "Maven Dependency Tree Bundle" [Resolved]
        org.maven.ide.eclipse.editor (0.12.1.20110112-1712) "Maven Integration for Eclipse (Editors)" [Active]
        org.maven.ide.eclipse.editor.xml (0.12.1.20110112-1712) "Maven POM XML Editor" [Active]
        org.maven.ide.eclipse.jdt (0.12.1.20110112-1712) "Maven Integration for Eclipse JDT" [Active]
        org.maven.ide.eclipse.launching (0.12.1.20110112-1712) "Maven Integration for Eclipse Launching" [Active]
        org.maven.ide.eclipse.maven_embedder (0.12.1.20110112-1712) "Embedded Maven Runtime Bundle" [Resolved]
        org.maven.ide.eclipse.maven_model_edit (0.12.1.20110112-1712) "Maven Project Model Edit Bundle" [Active]
        org.maven.ide.eclipse.nexus_indexer (0.12.1.20110112-1712) "Nexus Indexer Bundle" [Resolved]
        org.maven.ide.eclipse.plexus.annotations (0.12.0.20101103-1500) "Plexus Metadata Generation" [Resolved]
        org.maven.ide.eclipse.pr (0.12.1.20110112-1712) "Maven Problem Reporting" [Resolved]
        org.maven.ide.eclipse.refactoring (0.12.1.20110112-1712) "Maven Integration for Eclipse Refactoring" [Active]
        org.maven.ide.eclipse.temporary.mojos (0.12.0.20101103-1500) "Collection of project configurators (temporary)" [Resolved]
        org.maven.ide.eclipse.wtp (0.11.1.20101108-1810) "Maven Integration for Eclipse WTP" [Active]
        org.mortbay.jetty.server (6.1.23.v201004211559) "Jetty Server" [Resolved]
        org.mortbay.jetty.util (6.1.23.v201004211559) "Jetty Utilities" [Resolved]
        org.mozilla.javascript (1.7.2.v201005080400) "Mozilla Rhino" [Resolved]
        org.objectweb.asm (3.2.0.v200909071300) "ASM" [Resolved]
        org.polarion.eclipse.team.svn.connector (2.2.2.I20110318-1700) "Subversive SVN Connectors" [Resolved]
        org.polarion.eclipse.team.svn.connector.javahl16 (2.2.2.I20110523-1700) "Subversive SVN 1.6 JavaHL Connector" [Active]
        org.polarion.eclipse.team.svn.connector.svnkit16 (2.2.2.I20110523-1700) "Subversive SVN 1.6 SVN Kit Connector" [Active]
        org.sat4j.core (2.2.0.v20100429) "SAT4J Core" [Resolved]
        org.sat4j.pb (2.2.0.v20100429) "SAT4J Pseudo" [Resolved]
        org.sonatype.tycho.m2e (0.4.3.20101103-1630) "Tycho Project Configurators" [Active]
        org.springframework.aop (3.0.5.RELEASE) "Spring AOP" [Resolved]
        org.springframework.asm (3.0.5.RELEASE) "Spring ASM" [Resolved]
        org.springframework.batch.core (2.1.0.RELEASE) "Spring Batch Core" [Resolved]
        org.springframework.batch.infrastructure (2.1.0.RELEASE) "Spring Batch Infrastructure" [Resolved]
        org.springframework.beans (3.0.5.RELEASE) "Spring Beans" [Resolved]
        org.springframework.binding (2.0.7.A) "Spring Binding" [Resolved]
        org.springframework.context (3.0.5.RELEASE) "Spring Context" [Resolved]
        org.springframework.context.support (3.0.5.RELEASE) "Spring Context Support" [Resolved]
        org.springframework.core (3.0.5.RELEASE) "Spring Core" [Resolved]
        org.springframework.expression (3.0.5.RELEASE) "Spring Expression Language" [Resolved]
        org.springframework.faces (2.0.7.A) "Spring Faces" [Resolved]
        org.springframework.ide.eclipse (2.6.0.201103160035-RELEASE) "Spring IDE" [Resolved]
        org.springframework.ide.eclipse.ajdt.ui.visualiser (2.6.0.201103160035-RELEASE) "Spring IDE AOP Visualiser UI" [Starting]
        org.springframework.ide.eclipse.ajdt.ui.xref (2.6.0.201103160035-RELEASE) "Spring IDE AOP Xref UI" [Starting]
        org.springframework.ide.eclipse.aop.core (2.6.0.201103160035-RELEASE) "Spring IDE AOP Core" [Active]
        org.springframework.ide.eclipse.aop.mylyn (2.6.0.201103160035-RELEASE) "Spring IDE AOP Mylyn Integration" [Starting]
        org.springframework.ide.eclipse.aop.ui (2.6.0.201103160035-RELEASE) "Spring IDE AOP UI" [Active]
        org.springframework.ide.eclipse.aop.ui.matcher (2.6.0.201103160035-RELEASE) "Spring IDE AOP Pointcut Matcher" [Starting]
        org.springframework.ide.eclipse.batch (2.6.0.201103160035-RELEASE) "Spring IDE Support for Spring Batch" [Active]
        org.springframework.ide.eclipse.beans.core (2.6.0.201104111100-PATCH) "Spring IDE Beans Core" [Active]
        org.springframework.ide.eclipse.beans.core.autowire (2.6.0.201103160035-RELEASE) "Spring IDE Autowiring Support (Core)" [Active]
        org.springframework.ide.eclipse.beans.core.metadata (2.6.0.201103160035-RELEASE) "Spring IDE Metadata Support (Core)" [Active]
        org.springframework.ide.eclipse.beans.mylyn (2.6.0.201103160035-RELEASE) "Spring IDE Beans Mylyn Integration" [Active]
        org.springframework.ide.eclipse.beans.ui (2.6.0.201103160035-RELEASE) "Spring IDE Beans UI" [Active]
        org.springframework.ide.eclipse.beans.ui.autowire (2.6.0.201103160035-RELEASE) "Spring IDE Autowiring Support (UI)" [Starting]
        org.springframework.ide.eclipse.beans.ui.editor (2.6.0.201103160035-RELEASE) "Spring IDE Beans Config Editor" [Active]
        org.springframework.ide.eclipse.beans.ui.graph (2.6.0.201103160035-RELEASE) "Spring IDE Bean Dependency Graph" [Active]
        org.springframework.ide.eclipse.beans.ui.refactoring (2.6.0.201103160035-RELEASE) "Spring IDE Refactoring Support" [Active]
        org.springframework.ide.eclipse.beans.ui.search (2.6.0.201103160035-RELEASE) "Spring IDE Beans UI Search" [Starting]
        org.springframework.ide.eclipse.core (2.6.0.201104111100-PATCH) "Spring IDE Core" [Active]
        org.springframework.ide.eclipse.doc (2.6.0.201103160035-RELEASE) "Spring Framework Reference Documentations" [Resolved]
        org.springframework.ide.eclipse.integration (2.6.0.201103160035-RELEASE) "Spring IDE Support for Spring Integration" [Active]
        org.springframework.ide.eclipse.mylyn (2.6.0.201103160035-RELEASE) "Spring IDE Mylyn Integration" [Starting]
        org.springframework.ide.eclipse.osgi (2.6.0.201103160035-RELEASE) "Spring IDE Support for Spring Dynamic Modules for OSGi(tm) Service Platforms" [Starting]
        org.springframework.ide.eclipse.osgi.targetdefinition (2.6.0.201103160035-RELEASE) "Spring Dynamic Modules for OSGi(tm) Service Platforms Target Definition" [Active]
        org.springframework.ide.eclipse.security (2.6.0.201103160035-RELEASE) "Spring IDE Core Support for Spring Security" [Active]
        org.springframework.ide.eclipse.uaa (2.6.0.201104111100-PATCH) "Spring IDE Spring User Agent Analysis Integration" [Active]
        org.springframework.ide.eclipse.ui (2.6.0.201103160035-RELEASE) "Spring IDE UI" [Active]
        org.springframework.ide.eclipse.webflow.core (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow Core" [Active]
        org.springframework.ide.eclipse.webflow.mylyn (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow Mylyn Integration" [Active]
        org.springframework.ide.eclipse.webflow.ui (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow UI" [Active]
        org.springframework.ide.eclipse.webflow.ui.editor (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow Config Editor" [Active]
        org.springframework.ide.eclipse.webflow.ui.graph (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow UI Editor" [Starting]
        org.springframework.jdbc (3.0.5.RELEASE) "Spring JDBC" [Resolved]
        org.springframework.jms (3.0.5.RELEASE) "Spring JMS" [Resolved]
        org.springframework.js (2.0.7.A) "Spring JS" [Resolved]
        org.springframework.orm (3.0.5.RELEASE) "Spring ORM" [Resolved]
        org.springframework.osgi.core (2.0.0.M2-SNAPSHOT) "spring-osgi-core" [Resolved]
        org.springframework.osgi.io (2.0.0.M2-SNAPSHOT) "spring-osgi-io" [Resolved]
        org.springframework.oxm (3.0.5.RELEASE) "Spring Object/XML Mapping" [Resolved]
        org.springframework.security.config (3.0.2.RELEASE) "Spring Security Namespace Configuration" [Resolved]
        org.springframework.security.core (3.0.2.RELEASE) "Spring Security Core" [Resolved]
        org.springframework.security.web (3.0.2.RELEASE) "Spring Security Web" [Resolved]
        org.springframework.transaction (3.0.5.RELEASE) "Spring Transaction" [Resolved]
        org.springframework.web (3.0.5.RELEASE) "Spring Web" [Resolved]
        org.springframework.web.servlet (3.0.5.RELEASE) "Spring Web Servlet" [Resolved]
        org.springframework.webflow (2.0.7.A) "Spring Web Flow" [Resolved]
        org.springframework.ws (1.5.8.A) "Spring Web Services Core" [Resolved]
        org.springframework.xml (1.5.8.A) "Spring XML" [Resolved]
        org.uddi4j (2.0.5.v200805270300) "UDDI4J" [Resolved]
        org.zeroturnaround.eclipse (1.4.1.201106011211) "JRebel Eclipse Plug-in" [Active]
        org.zeroturnaround.eclipse.debug (1.4.0.201105311642) "JRebel Eclipse Debugger Plug-in" [Active]
        org.zeroturnaround.eclipse.embedder (4.0.0.201105311642) "Embedded JRebel for Eclipse" [Active]
        org.zeroturnaround.eclipse.wtp (1.4.0.201105311642) "JRebel WTP Integration Plug-in" [Starting]

Attachments: Text File greclipe-stacks.txt     Text File GRECLIPSE-1074-updatedeclipseerror.txt     Text File GRECLIPSE-1074-updateenvironment.txt    
Issue Links:
Related
relates to GRECLIPSE-1074 Opening Groovy File causes VerifyErro... Resolved
Number of attachments : 3

 Description   

I had this issue occur again. The issue occurred immediately after adding a groovy source folder (using the Eclipse build path editor) and then opening a Groovy class within that class. I was not able to get a lot of information because Eclipse shutdown (I believe I accidentally selected the button that is shown with this error to restart eclipse). After Eclipse is restarted everything works again as expected.

My environment has been changed quite a bit. I have attached a new file with the environment. A few highlights are:

It really seems like this issue occurs when a lot of new/updated Groovy code is introduced. Previously I think this may have been related to when I switched branches as mentioned in comment-271504. One other thing that may be relevant is that I use gmaven and m2e integration. I really do not know if that information helps, but thought I would make that as evident as possible.

Thanks again for your help and sorry for not being able to provide more details on this issue.



 Comments   
Comment by Andrew Eisenberg [ 19/Aug/11 ]

Cloned from GRECLIPSE-1074.

Unfortunately, it doesn't look like comments were copied over.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

It's not out of the question that gmaven could introduce code cache problems since running with m2e would mean that gmaven is partially executed in the same jvm as the workbench. I have no way of knowing this unless I can get a memory snapshot.

Just make sure that you are using at least the following settings in your STS.ini:

-Xmx1024m 
-Xms256m 
-XX:PermSize=64m 
-XX:MaxPermSize=256m 
-XX:ReservedCodeCacheSize=64m

A yourkit snapshot of the system after you see this problem again would be helpful. Although that being said, the last snapshot you sent me didn't show me anything too useful.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

I am searching for any mention of a leak in CodeCache in groovy, but can't find anything. It does seem like someone else had a vaguely similar problem:

http://stackoverflow.com/questions/6015873/eclipse-dies-every-few-minutes-with-latest-jdk-saying-out-of-space-in-codecache

and here:

http://www.apacheserver.net/trunk-build-problem-out-of-space-in-CodeCache-for-adapters-at1027069.htm

The solution in the second link was to set the MAVEN_OPTS to be this:

-Xmx1024m -Xms256m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:ReservedCodeCacheSize=64m

I am not sure how this would affect m2e since m2e is running inside of Eclipse/STS and would use the memory of Eclipse's JVM. But it is perhaps worth a try.

Comment by Robert Winch [ 19/Aug/11 ]

Thanks for the fast response on this. I have updated my .ini settings per your recommendation.

I'm not really particular about where this issue is tracked, but out of curiosity what makes you think the original issue was fixed? I realize that this error differs from the initial posting, but it aligns with the first error I got when opening the editor (see the greclipse-stacks.txt and this comment). Perhaps you noticed something I didn't or it has gotten confusing since I did not give all the information up front (sorry about that).

I will try and get another yourkit snapshot next time. I know this is a poor excuse, but I believe I am mistakenly restarting Eclipse before I realize what has happened (this is an unfortunate side effect of using a lot of key bindings, the error dialog having a restart option on it, and my fingers thinking they are smarter than my brain).

A little more information on the gmaven is that I had some difficulty getting the m2e 1.0 groovy integration to work. I kept getting a maven error "Plugin execution not covered by lifecycle configuration". I resolved this by adding the lifecycle-mapping plugin set to execute. The problems I was having are probably more appropriate for GRECLIPSE-1068, but I thought it would be beneficial to know I was using the lifecycle-mapping since gmaven may have a part in this and it impacts how things work behind the scenes. I'm really beginning to think this issue is occurring because gmaven is being invoked by Eclipse. After all, these sort of issues were the reason that the m2e team decided not to directly support running maven plugins in Eclipse.

Thanks again for all your help!

PS: I do plan on trying to give feedback on the new m2e integration with the troubles I have had but at the moment I need to focus on "real work" as much as possible.

Comment by Robert Winch [ 19/Aug/11 ]

I can go ahead and give the MAVEN_OPTS a try, but I am doubting that this is the fix I need. The reason I doubt this is because we have a Jenkins build that has never ran into this issue. I verified and the jekins build does not define the ReservedCodeCacheSize.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

I agree that the MAVEN_OPTS is unlikely to work, but I don't think it would hurt anything.

I currently, Groovy-Eclipse m2e support for 1.0 is not really working. I hope to have a new version out later today. Once this is available, you should no longer have the "Plugin execution not covered by lifecycle configuration" errors appearing. And this may (just may) in turn affect your codecache problems.

When the m2e support is available, I'll post a comment on this bug.

I closed the first bug because you are no longer getting a verify error (unless I missed something). The verify errors were happening for known reasons and all of that has been addressed already. The codecache problem is something different, however.

Comment by Robert Winch [ 19/Aug/11 ]

>> When the m2e support is available, I'll post a comment on this bug.

Thank you

>> I closed the first bug because you are no longer getting a verify error (unless I missed something). The verify errors were happening for known reasons and all of
>> that has been addressed already. The codecache problem is something different, however.

In the previous issue I posted the the Verify Error on the initial bug description. However, it turned out (as mentioned in this comment) that there was a Code Cache error that happened first and then subsequent openings caused the editor to give the Verify Error. You can see both the Verify and Code Cache errors in the greclipe-stacks.txt I did not have the opportunity to the editor again because I clumsily selected to restart eclipse from the error dialog. I suspect if I had been able to open it again I would have gotten the Verify error. Please note I am not trying to be rude. I just wanted to ensure that you knew that I still believe it is the same issue as this information might be useful.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

I understand your confusion. And maybe you are right, that the code cache problem caused the verify error.

On the one hand, because you were getting a verify error and now you are not, this implies that a build that you picked up has fixed it. Furthermore, I don't see how a code cache problem would be causing a verify error (it would cause lots of other problems, but probably not that).

On the other hand, even if this is the same problem, I'm not too fussed about opening a new issue for it. The summary now correctly encapsulates the problem and helps focus on the main issues.

Comment by Robert Winch [ 19/Aug/11 ]

No problem. Just wasn't sure if some of the information on the other issue might be helpful in figuring out this issue.

Comment by Robert Winch [ 30/Aug/11 ]

For better or worse I am fairly convinced this issue has resolved itself. I believe increasing the code cache helps an issue that is happening in the gmaven plugin. If you like you can probably close the issue. If happens again I can either have it reopened or log a new JIRA.

Comment by Andrew Eisenberg [ 31/Aug/11 ]

Thanks for keeping up with this bug. I'll take your word for it that it is fixed. At least we now know that gmaven may be leaking the code cache and that a groovy-eclipse configurator for m2e 1.0 will likely avoid this problem.

Please re-open or create a new issue if you see the problem again.





[GRECLIPSE-1180] NPE in when performing rename method refactoring Created: 18/Aug/11  Updated: 18/Aug/11  Resolved: 18/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring, Search
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse.buildId=I20110613-1736
java.version=1.6.0_26
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_CA
Framework arguments: -product org.eclipse.sdk.ide
Command-line arguments: -product org.eclipse.sdk.ide -data /home/kdvolder/workspaces-sts/junit-workspace -dev file:/home/kdvolder/workspaces-sts/sts-grails/.metadata/.plugins/org.eclipse.pde.core/junit workspace/dev.properties -os linux -ws gtk -arch x86 -consoleLog


Number of attachments : 0

 Description   

I encountered this error when trying to rename a controller method in a Grails 2.0 project (this is without using any special grails refactoring support, just a 'plain' method rename).

Error
Thu Aug 18 13:50:57 PDT 2011
Error performing search for SongController.groovy

java.lang.NullPointerException
	at org.eclipse.jdt.groovy.search.MethodReferenceSearchRequestor.removeArray(MethodReferenceSearchRequestor.java:315)
	at org.eclipse.jdt.groovy.search.MethodReferenceSearchRequestor.acceptASTNode(MethodReferenceSearchRequestor.java:143)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleRequestor(TypeInferencingVisitorWithRequestor.java:1592)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleExpression(TypeInferencingVisitorWithRequestor.java:773)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstantExpression(TypeInferencingVisitorWithRequestor.java:1263)
	at org.codehaus.groovy.ast.expr.ConstantExpression.visit(ConstantExpression.java:73)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitMapEntryExpression(CodeVisitorSupport.java:197)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMapEntryExpression(TypeInferencingVisitorWithRequestor.java:1314)
	at org.codehaus.groovy.ast.expr.MapEntryExpression.visit(MapEntryExpression.java:37)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitListOfExpressions(CodeVisitorSupport.java:276)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitMapExpression(CodeVisitorSupport.java:191)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMapExpression(TypeInferencingVisitorWithRequestor.java:1324)
	at org.codehaus.groovy.ast.expr.MapExpression.visit(MapExpression.java:53)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitListOfExpressions(CodeVisitorSupport.java:276)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitTupleExpression(CodeVisitorSupport.java:178)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitTupleExpression(TypeInferencingVisitorWithRequestor.java:1532)
	at org.codehaus.groovy.ast.expr.TupleExpression.visit(TupleExpression.java:78)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1358)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitReturnStatement(CodeVisitorSupport.java:73)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitReturnStatement(ClassCodeVisitorSupport.java:224)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitReturnStatement(TypeInferencingVisitorWithRequestor.java:1209)
	at org.codehaus.groovy.ast.stmt.ReturnStatement.visit(ReturnStatement.java:47)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1194)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstructorOrMethod(TypeInferencingVisitorWithRequestor.java:645)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:389)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:235)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:190)
	at org.codehaus.jdt.groovy.integration.internal.GroovyLanguageSupport.maybePerformDelegatedSearch(GroovyLanguageSupport.java:188)
	at org.codehaus.jdt.groovy.integration.LanguageSupportFactory.maybePerformDelegatedSearch(LanguageSupportFactory.java:96)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1028)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1156)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1288)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:593)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.findAllDeclarations(RippleMethodFinder2.java:356)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.findAllRippleMethods(RippleMethodFinder2.java:187)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getAllRippleMethods(RippleMethodFinder2.java:168)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getRelatedMethods(RippleMethodFinder2.java:161)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.initializeMethodsToRename(RenameMethodProcessor.java:244)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.doCheckFinalConditions(RenameMethodProcessor.java:370)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.doCheckFinalConditions(RenameVirtualMethodProcessor.java:146)
	at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:48)
	at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:224)
	at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85)
	at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)


 Comments   
Comment by Andrew Eisenberg [ 18/Aug/11 ]

I can reproduce the problem with this simple class:

class Foo {
     def flar() { 
          "flar"
     }
}

The problem comes about because we are trying to determine if the "flar" string literal is actually a method reference. To do that, we are currently checking the declaring type of the expression, but since it is a string literal, it has no declaring type, hence the NPE. We can avoid this problem by a simple null check.

Comment by Andrew Eisenberg [ 18/Aug/11 ]

Fixed with regression test. Of course, I can't commit yet, though.





[GRECLIPSE-1179] Selectively run "safe" ast transforms as part of a reconcile operation Created: 18/Aug/11  Updated: 15/Mar/12  Resolved: 15/Mar/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.7.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by GRECLIPSE-1406 selectively allow some ast transforms... Resolved
dependent
is depended upon by GRECLIPSE-1171 @Field not supported in editor Resolved
Number of attachments : 0

 Description   

Currently, AST transforms are disabled when run as part of a reconcile operation. However, this means that some valid code will be seen as errors when viewed in the editor (even thought the groovy script/application will run correctly when launched).

There should be a way of determining that certain AST transforms are "safe" to run in the editor. "Safe" transforms are ones that only require local state and are purely additive. Things like @Delegate and @Singleton would be safe, byt things like @Lazy would not (since code blocks get moved around).



 Comments   
Comment by Andrew Eisenberg [ 18/Aug/11 ]

The most promising way that I can see this happening is through the use of a meta-annotation. An AST transform class (or the annotation associated with it will have this annotation on it and this would mean that the transform creator takes all responsibility for safety.

The biggest problem here is that determining if a transform has this annotation is expensive if it is done on every reconcile. If we keep track of this through caching, then it is problematic to keep the cache up to date as source code changes.

Comment by Andrew Eisenberg [ 15/Mar/12 ]

Andy is looking into this problem now, but under a different jira issue.





[GRECLIPSE-1177] Java 7 support: java.lang.NoClassDefFoundError: org/codehaus/groovy/eclipse/refactoring/formatter/GroovyIndentationService Created: 12/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release, 2.5.2.Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Blocker
Reporter: Marcelo Mrack Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: Java_7
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Greclipse 2.5.2.xx-20110811-2100-e37 (NOTE: The same error occurs with Greclipse 2.5.1)
Eclipse Indigo Version: 3.7.0 Build id: M20110729-1400 running on Sun JDK 1.7.0 (build 1.7.0-b147) Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
OS Windows 7 Ultimate 64bits SP1 (Version 6.1.7601)
Groovy 1.8.1 and/or 1.7.5


Attachments: Text File greclipse-error.log     PNG File groovyEclipseError.png     PNG File groovyEclipseVersionDetails.png    
Number of attachments : 3

 Description   

Steps to reproduce:
1. Install plugin from http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
2. Create a Groovy project.
3. Create a Groovy class.
4. When screen changes to Groovy editor window (or anytime that Groovy editor is called), the attached error is raised.



 Comments   
Comment by Andrew Eisenberg [ 12/Aug/11 ]

I'll figure out what's going on. I may have some more questions to ask to help pinpoint the error.

Comment by Andrew Eisenberg [ 12/Aug/11 ]

Thanks. One thing that comes to mind immediately is that you are running on Java 7. Although there are no known issues with running Groovy-Eclipse on Java 7, we haven't done any testing for it.

Another thing, can you check your error log to see if there are any other related errors that happened earlier?

Window -> Show View -> Error log

Comment by Andrew Eisenberg [ 12/Aug/11 ]

Thanks for your help in getting me to track this down. As we talked about in our skype session, the problem is that you installed a dev build of Eclipse 3.7.1 and this overrides support for the groovy-eclipse core patch. The patch only works on 3.7.0. In the next few weeks, we will be working on support for 3.7.1 (and Java 7).

I'll update this bug when we have some support for 3.7.1 as a snapshot.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

Update summary and add label to more clearly reflect the problem.

Comment by Andrew Eisenberg [ 08/Sep/11 ]

Duplicate of GRECLIPSE-1156





[GRECLIPSE-1176] switching compiler versions with 1.8.1 and 1.8.0 bundles around switches just between 1.8.1 and 1.8.0 (rather than back to 1.7.10) Created: 11/Aug/11  Updated: 30/Aug/11  Resolved: 18/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

if I have upgraded to 1.8.1 and have a 1.8.0 around, clicking 'switch to 1.7' seems to take me to 1.8.0.



 Comments   
Comment by Andrew Eisenberg [ 12/Aug/11 ]

Ah. I see that the version range specified for the 1.8 compiler was "1.8.1". It should be "[1.8.0,1.9.0)". When I test this locally, it seems that the problem is fixed.

The groovy svn repo is currently closed for commits, but I will commit the change when it opens again.

Comment by Andrew Eisenberg [ 18/Aug/11 ]

Fixed, even though cannot yet commit.

Comment by Lari Hotari [ 26/Aug/11 ]

I'm using STS 2.8.0.M1 + Groovy-Eclipse 2.5.2.xx-20110811-0900-e37 and Groovy 1.7.10 and 1.8.1 compiler features. Switching doesn't work at all between 1.7 and 1.8 compilers.

I also tried -vmargs -Dgroovy.compiler.level=17 / 18 way , but that doesn't work either: java.lang.IllegalArgumentException: Specified version of Groovy not found. Available versions are (empty list).

I hope this problem is fixed too.

As a workaround I'm switching compiler versions by editing the bundles.info file directly (http://en.appsatori.eu/2011/05/easy-switching-between-groovy-eclipse.html).

Comment by Andrew Eisenberg [ 30/Aug/11 ]

Lari,

Apologies for the late response, but I have just returned from vacation.

I see that the version you are using is from August 11, but this bug was resolved on August 18. We had a bit of difficulty pushing out a release due to the migration of groovy core to git from svn (the greclipse svn repo was closed for commits during this time).

My best suggestion is to try again with the latest dev snapshot and see if it works.

Also, as a side note, we are deprecating -vmargs -Dgroovy.compiler.level=17 because using this on the command line will cause the equinox osgi framework to ignore all vmargs coming from eclipse.ini.

Instead, you should be using -groovy.compiler.level 17 as a regular command line argument.

Please let me know if this solves your problems.





[GRECLIPSE-1175] Code completion throws exception Created: 10/Aug/11  Updated: 12/Aug/11  Resolved: 12/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Critical
Reporter: Cary Maister Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, STS 2.7.1


Attachments: Text File sts-installation-details.txt    
Number of attachments : 1

 Description   

I'm using SpringSource Tool Suite 2.7.1 and just got the automated upgrade of Groovy-Eclipse to release 2.5.2.xx-20110808-1500-e37. Since I got the upgraded, I've started experiencing the below error from Code Completion.

Steps to reproduce:

  1. Open a Groovy class (either newly created, or an existing class.)
  2. Create an class variable and attempt to use Code Completion on the right side of the assignment, e.g.:
    class MyClass {
        def something = Class
    }
    

    Then select "Class" and press ctrl-space OR type "." after Class

  3. STS will give a pop-up error message saying "The 'Groovy Code Completions' proposal computer from the 'org.codehaus.groovy.eclipse.codeassist.completion' plug-in did not complete normally. The extension has thrown a runtime exception."

I've found that this occurs whether the declared variable is static or not, whether it is declared with a class name or with "def" and whether the code completion is attempted statically for a class (as in my example) or on another class variable.

I'm attaching the error info, as well as my STS installation details in case that's useful.



 Comments   
Comment by Cary Maister [ 10/Aug/11 ]

Error info:
eclipse.buildId=2.7.1.201107091000-RELEASE
java.version=1.6.0_17
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -product com.springsource.sts.ide
Command-line arguments: -os win32 -ws win32 -arch x86 -product com.springsource.sts.ide

Warning
Wed Aug 10 12:56:17 EDT 2011
The 'Groovy Code Completions' proposal computer from the 'org.codehaus.groovy.eclipse.codeassist.completion' plug-in did not complete normally. The extension has thrown a runtime exception.

java.util.EmptyStackException
	at java.util.Stack.peek(Stack.java:85)
	at org.codehaus.groovy.eclipse.codeassist.requestor.CompletionNodeFinder.visitClassExpression(CompletionNodeFinder.java:445)
	at org.codehaus.groovy.ast.expr.ClassExpression.visit(ClassExpression.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitProperty(ClassCodeVisitorSupport.java:142)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1145)
	at org.codehaus.groovy.eclipse.codeassist.requestor.CompletionNodeFinder.visitClass(CompletionNodeFinder.java:198)
	at org.codehaus.groovy.eclipse.codeassist.requestor.CompletionNodeFinder.internalVisitModuleNode(CompletionNodeFinder.java:127)
	at org.codehaus.groovy.eclipse.codeassist.requestor.CompletionNodeFinder.findContentAssistContext(CompletionNodeFinder.java:112)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.createContentAssistContext(GroovyCompletionProposalComputer.java:196)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.internalComputeCompletionProposals(GroovyCompletionProposalComputer.java:143)
	at org.codehaus.groovy.eclipse.codeassist.requestor.GroovyCompletionProposalComputer.computeCompletionProposals(GroovyCompletionProposalComputer.java:108)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:318)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:267)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:283)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:243)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1830)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:488)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482)
	at org.eclipse.jface.text.contentassist.ContentAssistant$2.run(ContentAssistant.java:377)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
Comment by Cary Maister [ 10/Aug/11 ]

Just noticed: The version for this should be 2.5.2Release

Comment by Andrew Eisenberg [ 10/Aug/11 ]

I initially got tripped up because of the capital 'C' in 'Class', but after making it lower case, I can see the problem. This is a bug.

Comment by Cary Maister [ 10/Aug/11 ]

just curious, shouldn't it be a bug for Class with a capital C, too? In that case I'd expect code completion to supply the valid static fields/methods from the Class class? (I guess "Class" was a confusing choice for my example)

Comment by Andrew Eisenberg [ 12/Aug/11 ]

Class with a 'C' for the class declaration will cause a syntax error in the file and the file will not be able to be properly parsed. So, you will not get any content assist proposals, but there will be no exception thrown either.

Comment by Andrew Eisenberg [ 12/Aug/11 ]

Fixed with regression test. Will be available in next snapshot build.





[GRECLIPSE-1174] Type not inferred on (1 as int).intValue() Created: 09/Aug/11  Updated: 18/Aug/11  Resolved: 18/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

2.1.3.xx-20110808-1500-e37


Number of attachments : 0

 Description   

The following does not infer the type of the expression to be int:

(1 as int).intValue()


 Comments   
Comment by Andrew Eisenberg [ 18/Aug/11 ]

What I see is that the type is inferred to be java.lang.Integer. For the purposes of inferencing, Integer and int are equivalent.

Comment by Andrew Eisenberg [ 18/Aug/11 ]

I am closing as unreproducible, but please re-open if you can supply something that can show the problem.

I will beef up the tests in this area anyway.





[GRECLIPSE-1173] GSP/Scaffolding template editor adds spurious "Comment not closed" annotations Created: 08/Aug/11  Updated: 31/Aug/11  Resolved: 08/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: D Gardner Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.7.1, Groovy-Eclipse 2.5.1


Number of attachments : 0

 Description   

When editing Grails GSP scaffolding templates, I get a lot of spurious annotations in the editor reporting "Comment not closed". These are accompanied by wavy red underlining that can cover most of the file and make it difficult to edit. Hovering on the annotation marker at the edge of the editor, I see:

Multiple annotations found at this line:
 - Comment not closed

There are no comments in the file (I reported a Grails bug about comments, as the code generator falls over if I insert a GSP comment into a scaffolding template). I'm also not sure how one annotation counts as "Multiple annotations", but perhaps that is part of the cause of the problem.

The problem happens seemingly at random. The only way I've found to clear the error is to cut the contents of the file and paste it right back again (unchanged). If I insert a HTML/XML comment into the file (which I don't do normally, as they show up in the browser), then I'll sometimes get the same warning and see the first few lines of the comment (but not all lines) underlined. This can happen when the comment is properly closed.

I have been unable to find a reliable way to reproduce this issue. My suspicion, though, is that it might relate to annotation markers getting "stuck" while I'm typing a comment (or something that is briefly interpreted by the editor as a comment) and then these markers not getting cleared properly. If I deliberately leave a comment open, I get the annotation marker warning me, but I don't get the "Multiple annotations found at this line" bit, just a single "Comment not closed" annotation. Could there be a build up of stray annotation markers happening? Perhaps a code review might uncover something.



 Comments   
Comment by Andrew Eisenberg [ 08/Aug/11 ]

This is an STS issue. I am closing this bug and I raised:
https://issuetracker.springsource.com/browse/STS-1992

Please make all further comments on that issue.

Can you attach a sample template file that had this problem at one time (even if you are no longer seeing it now)?

Comment by Andrew Eisenberg [ 15/Aug/11 ]

I'm unable to do much on this issue without any further information. Can you attach a gsp file where this has happened to you? Also, do you see any entries in the error log about this? Aso, after you see this problem, can yo right click on the gsp file and select "validate"? Does the error go away?

Please comment on the STS issue that I have linked to.

Comment by D Gardner [ 17/Aug/11 ]

I don't have an account there. Maybe you can paste this in for me:

It happens in the Grails 1.3.7 OOTB "show.gsp" scaffolding template.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

I am still not able to reproduce. I will close the issue on STS, but will re-open if you can give me some more specific instructions on how to reproduce.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

I have been playing around a little more and I found something suspicious. If I type this into the editor:

${message}<g:if test="">

I get the same "Comment not closed" error. However, this is invalid syntax. If I fix the syntax, and add the trailing />, then the error goes away.

Similarly,

<%-- ${message}  -->

is illegal since you cannot put groovlets inside of serverside comments.

Could either of these issues explain your problem?

Comment by D Gardner [ 20/Aug/11 ]

I stripped down the "show.gsp" scaffolding template and could reproduce the essence of the issue with the following short content in a "bug.gsp" file:

<% import java.lang.String %>
<html>
  <body>
    <g:message code="${domainClass.propertyName}.label"/>
  </body>
</html>

If I delete the greater-than sign ">" at the end of the opening "<html>" tag, I get the "Comment not closed" error. Now, if I replace the ">", the error does not go away. This is a little different than in the full "show.gsp" file, as there I get the "Multiple annotations..." message. However, the fundamental nature is the same: the annotation gets stuck and I have to cut the full contents of the file and paste it back before the error is cleared.

I noted that if I remove the "import" line or the expression in the value of the "code" attribute that the error does not occur. (The "show.gsp" imports the "grails.persistence.Event" class, but "java.lang.String" works just as well to reproduce the issue. I mention that just in case you think I'm a "crazy person"!)

Concerning your first example in your comment above, the issue is not that the error (even the wrong error) is reported, but that when the content is corrected that the error gets "stuck". Perhaps the issue relates to some misinterpretation of the angle brackets in the GSP "import" line under some circumstances. Maybe it is being confused with a HTML tag or comment in some way.

Your second example is also illegal because the GSP comment sequence is "<%-- --%>" (at least according to the Grails docs). Not that GSP comments work in a scaffolding template, though. I reported that as a separate issue in the Grails bug database, as they make the Grails build fall over.

Comment by Andrew Eisenberg [ 31/Aug/11 ]

Thanks for the detailed information on how to recreate. I now see exactly the error that you are talking about and can easily reproduce. I'll take a look to see what I can do to fix it.

And, no, I never thought you were a "crazy person".

Comment by Andrew Eisenberg [ 31/Aug/11 ]

I found the problem. The GSP validators were not being configured properly for the right document partition types. I had originally copied this from the JSP validators, but GSP syntax is different in certain areas.

The validators work on specific partition types. What is supposed to happen is that when a syntax error appears, there is a validator that is called for a particular partition type (eg- html, or javascript, or groovy) and that discovers the error, adding the red squigglies in the editor. When the error is fixed, the partition type may have changed and so another validator must kick in to remove the red squigglies.

The problem was that in GSP when the syntax error was fixed, there was no validator to kick in to remove the errant squiggly.

I fixed the problem for the case that you have, as well as another related case. I couldn't find any more cases, but that doesn't mean they don't exist. After you upgrade to the latest dev build of STS grails tooling, keep an eye out to see if you find any more errant squigglies and I will address them as well.





[GRECLIPSE-1172] Unwanted automatic closing of braces in a GString Created: 07/Aug/11  Updated: 31/Aug/11  Resolved: 17/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Project Settings
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: D Gardner Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.7.1, Grails 1.3.7


Number of attachments : 0

 Description   

On typing "${" in a GString, the editor will immediately add a closing brace "}" character after the cursor, even if the Java Editor preferences specify not to automatically close braces. I expect these editor preferences to be inherited by the Groovy Editor. These unwanted closing braces interfere with my ability to type fluidly, are a constant source of annoyance, and cause a lot of accidental errors while coding.

This issue might relate to behaviour introduced by the patch for issue GRECLIPSE-795. A comment there states:

This patch adds auto insertion of "}" braces after "${" while editing Strings.

A little of extra logic was also added to not insert the extra closing brace if it seems there's one already there.

Please fix this issue and respect the Java Editor preference not to automatically close braces.



 Comments   
Comment by Andrew Eisenberg [ 07/Aug/11 ]

Assigning this one to Kris since he was the one who originally created the patch.

Comment by D Gardner [ 11/Aug/11 ]

If the worst comes to the worst and, for whatever reason, it is necessary to insert a "}" into my code against my wishes, it would be less terrible if I could move the cursor after the "}" using the Tab key. This kind of Tab key cursor positioning is a common feature in Eclipse editors when code templates or other kinds of auto-completion are used.

Comment by Andrew Eisenberg [ 17/Aug/11 ]

You're lucky. 3 of your bugs to be fixed in one day.

I took a look at this one as well and I have a fix for it locally. It seems like the autoclose for refs in GStrings was implemented differently from other autoclosers. I folded this implementation into the existing infrastructure that handles autoclosing of (, <, ", ', """, and '''.

I also linked the preference to the Preferences -> Java -> Editor -> Typing -> Automatically Close -> Braces. Uncheck that option and the braces will not auto-close for you.

Comment by Andrew Eisenberg [ 17/Aug/11 ]

Fixed with regression tests, but will wait to commit this until svn repo is open for commits again.

Comment by D Gardner [ 20/Aug/11 ]

Thank you very much, Andrew. I really appreciate the attention that you've been giving to the issues that I have reported over the past few weeks.

Does auto-complete still work as expected with the changes you have made? I notice that auto-complete usually breaks if the closing brace is not present in the GString. I suspect that is the reason why GRECLIPSE-795 added the brace if it was missing. It wasn't the right fix (to my mind), but I wonder if removing it the automatic closing will regress that earlier issue.

Comment by Andrew Eisenberg [ 31/Aug/11 ]

Having an unclosed curly in a gstring will cause the groovy parser to fail and none of the file will be able to be parsed.

The fix that I made for this bug was to use a different and more precise mechanism to autoclose. Now, they are autoclosed only if the preference is set. Also, pressing tab or an extra '}' will navigate you to outside of the closing curly. So. there should not be any regression.





[GRECLIPSE-1171] @Field not supported in editor Created: 06/Aug/11  Updated: 15/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Dominik Leszyk Assignee: Unassigned
Resolution: Fixed  
Labels: stability, triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7; Groovy-Eclipse plugin Version: 2.5.1.xx-20110628-1600-e37


Issue Links:
dependent
depends upon GRECLIPSE-1179 Selectively run "safe" ast transforms... Resolved
Number of attachments : 0

 Description   

The following code:

import groovy.transform.Field

@Field List awe = [1, 2, 3]
def awesum() { awe.sum() }
assert awesum() == 6

leads to error in the editor: 'Groovy:Error: annotation @Field can only be used within a Script body.'. When creating Groovy Class, I marked 'Create Script' checkbox.



 Comments   
Comment by Andrew Eisenberg [ 19/Aug/11 ]

I am not seeing the editor problem that you are. I am running on the latest dev snapshot where things may have changed a bit. However, in the editor an in the inferencing engine, the @Field transform has not been applied. Currently, this is by design since there are many transforms out there that are not well behaved (such as @Lazy). Applying them in the editor will break editing functionality. We are considering a way to selectively run some transforms in the editor. See GRECLIPSE-1179.

That being said, is the compiler problem that you are seeing only appearing in the editor or do you see it in the problems view as well?

Comment by Dominik Leszyk [ 20/Aug/11 ]

Compiler problem appears in both: in the editor (error marker) and in the Problems view. Previously I haven't bothered to run this script but now I see it works when started with Run As Groovy Script.

Comment by Andrew Eisenberg [ 24/Apr/13 ]

It will be possible to get this working by enabling a few flags internally to ensure AST transforms are run during reconcile and then to add this transform to your project build settings. I added a 2.8.0 resolve version to see if we should enable this by default.

Comment by Andrew Eisenberg [ 24/Apr/13 ]

So, if you manually edit your project's .settings/org.eclipse.jdt.core.prefs file and add a line like this:

org.eclipse.jdt.core.compiler.groovy.groovyTransformsToRunOnReconcile=org.codehaus.groovy.transform.FieldASTTransformation

You will get it to work. But, only after I make a change in Groovy-Eclipse to respect that setting.

Comment by Denis Murashev [ 14/Jul/14 ]

Looks like already fixed (at least in version 2.9.0.RELEASE).

Comment by Denis Murashev [ 15/Sep/14 ]

Closed as cannot be reproduced and there is no updates.





[GRECLIPSE-1170] If a field has an initializer with a known static type, should use that type as the field's type Created: 05/Aug/11  Updated: 19/Aug/11  Resolved: 19/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to GRECLIPSE-1139 Content assist for closure arguments Resolved
Number of attachments : 0

 Description   

In this case:

class Foo {
  def x = 9
}

We should infer that the type of Foo.x is int.



 Comments   
Comment by Andrew Eisenberg [ 18/Aug/11 ]

I have something working locally that appears to be a good fix. I need to write up some more tests before I can close this issue.

Comment by Andrew Eisenberg [ 18/Aug/11 ]

Unfortunately, this fix only works when referring to a field defined in the current file. When referring to an external field, the initializer is not available, so this mechanism will not work directly.

We are considering altering the schema of external ClassNodes so that they will contain field initializers (when they are constants) just so we can get this working.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

I accepted a patch from Andy Clement (up until recently, the SVN repo was closed for commits). It does make the initializer available in the field, but there is another problem that this uncovered.

When the field is a property (ie- it has no modifiers), then the field is created twice: once during the parse, and then once again because of the property. This is wrong. It looks like JDTClassNode.createPropertyNodeForMethodNode is being called on the getter method for that field and accidentally creating a second field with the same name.

I think I know how to fix now.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

Fix appears to be working. Now, the JDTClassNode.createPropertyNodeForMethodNode method tries to use an existing field, and if it can't find any, then it creates one.

I will write up some tests for this.

The only problem that I can think of is that what if the field is actually declared in a super class? Not sure if this is a problem we need to deal with.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

The new tests are passing fine.

It looks like if the field is declared in a super type, then the property is added to the super type (ie- there is no problem with the scenario described in the previous question).

Comment by Andrew Eisenberg [ 19/Aug/11 ]

Code is committed with regression tests.





[GRECLIPSE-1169] MapWithDefault.newInstance should infer key type in supplied closure Created: 03/Aug/11  Updated: 20/Dec/11  Resolved: 20/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.1.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GRECLIPSE-1129 Type parameters on methods are not re... Resolved
Number of attachments : 0

 Description   

The following should infer the key type (String in this example) from the supplied map:

MapWithDefault.newInstance([x:1] ) {  
    it.toUpperCase()
}


 Comments   
Comment by Andrew Eisenberg [ 03/Aug/11 ]

This is a problem with type parameters on methods. I can hard code this particular instance, but I'd prefer a more general approach.

Comment by Andrew Eisenberg [ 20/Dec/11 ]

Closing this issue since it would be addressed by GRECLIPSE-1129.





[GRECLIPSE-1168] Error on "Run As | Groovy Script" for script with class definition Created: 03/Aug/11  Updated: 19/Aug/11  Resolved: 19/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ClassTest.launch     PNG File eclipse-versions.png     PNG File groovy-eclipse-compile-bug.png     File groovy-error.tgz    
Number of attachments : 4

 Description   

The following script:

Foo foo = new Foo()

class Foo {
    int f
}

produces the following error to stderr when launched with "Run As | Groovy Script":

Caught: java.lang.AbstractMethodError
java.lang.AbstractMethodError


 Comments   
Comment by Andrew Eisenberg [ 03/Aug/11 ]

How exactly are you running this? What are you selecting when you do the Run As?

I selected the script file, right-click -> Run As -> Groovy Script. And I had no problems.

Comment by Bob Tiernay [ 04/Aug/11 ]

Yes. Also launching with "Run As | Groovy Console" produces a similar error in groovyConsole, this time with a full stack trace:

groovy> Test t = new Test() 
groovy> println t 
groovy> class Test { 
groovy>     int f 
groovy> } 
 
Exception thrown
4-Aug-2011 7:50:58 AM org.codehaus.groovy.runtime.StackTraceUtils sanitize
WARNING: Sanitizing stacktrace:
java.lang.AbstractMethodError
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:266)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:366)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1058)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174)
	at org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:763)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:957)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:542)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:520)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
	at groovy.lang.GroovyShell.run(GroovyShell.java:516)
	at groovy.lang.GroovyShell.run(GroovyShell.java:172)
	at groovy.lang.GroovyShell$run.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy:924)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:883)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:883)
	at groovy.lang.Closure.call(Closure.java:410)
	at groovy.lang.Closure.call(Closure.java:404)
	at groovy.lang.Closure.run(Closure.java:488)
	at java.lang.Thread.run(Thread.java:662)

java.lang.AbstractMethodError

See attached image as well.

Comment by Bob Tiernay [ 04/Aug/11 ]

Error in groovyConsole

Comment by Bob Tiernay [ 04/Aug/11 ]

Also of note that if I run the same script in groovyConsole from the command line, this script works as expected. Both versions are 1.8.1

Comment by Bob Tiernay [ 04/Aug/11 ]

Version info:

Feature Id Version
org.codehaus.groovy.jdt.patch 2.1.3.xx-20110729-1800-e37
org.codehaus.groovy.eclipse.feature 2.5.2.xx-20110729-1800-e37
org.codehaus.groovy17.feature 2.5.2.xx-20110729-1800-e37
org.codehaus.groovy18.feature 2.5.2.xx-20110729-1800-e37
Comment by Bob Tiernay [ 04/Aug/11 ]

Also of note, if I switch to version 1.7 of Groovy in the preferences and restart, it works. If I switch back to 1.8 and restart, it ceases to work. Note that this is the only project open in my workspace.

Comment by Bob Tiernay [ 04/Aug/11 ]

Also, if I "Run As | Java Application" it also works with 1.8 configured

Comment by Andrew Eisenberg [ 04/Aug/11 ]

I think this may have to do with your launch configuration. It may be that your script is compiled using Groovy 1.8, but the launch config tries to launch using groovy 1.7.

Can you attach your launch configuration here? Do this by first saving the config to a file:

Run As -> Run Configurations... -> <Choose_your_launch_config> -> Common and select "Shared file". Attach the file that was saved.

Comment by Bob Tiernay [ 04/Aug/11 ]

Launch configuration showing error condition

Comment by Andrew Eisenberg [ 04/Aug/11 ]

Thanks for the attachment. I think I see the problem. There is a section in the launch configuration where the launched process's classpath is explicitly specified.

<listAttribute key="org.eclipse.jdt.launching.CLASSPATH">
<listEntry value="/local/btiernay/workspace/greclipse-test1/bin"/>
<listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/groovy-all-1.8.1.jar"/>
<listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/ivy-2.2.0.jar"/>
<listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/commons-cli-1.2.jar"/>
<listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/jline-0.9.94.jar"/>
<listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/servlet-api-2.4.jar"/>
<listEntry value="/local/btiernay/.groovy/greclipse/global_dsld_support"/>
<listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/plugin_dsld_support/"/>
</listAttribute>

If you remove that section from the launch configuration, it should work. If the CLASSPATH attribute is left unspecified, then a default one will be created.

Please let me know if this works for you. It does for me.

Comment by Bob Tiernay [ 04/Aug/11 ]

After making the recommended changes, my launch configuration now looks like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.codehaus.groovy.eclipse.groovyScriptLaunchConfiguration">
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
<listEntry value="/greclipse-test1"/>
</listAttribute>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
<listEntry value="4"/>
</listAttribute>
<stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="org.codehaus.groovy.tools.GroovyStarter"/>
<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="--classpath &quot;${workspace_loc:/greclipse-test1}/src:${workspace_loc:/greclipse-test1}/bin&quot; --main groovy.ui.GroovyMain &quot;${resource_loc:/greclipse-test1/src/ClassTest.groovy}&quot;"/>
<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="greclipse-test1"/>
<stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Dgroovy.starter.conf=&quot;${groovy_home}/conf/groovy-starter.conf&quot; -Dgroovy.home=&quot;${groovy_home}&quot;"/>
<stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value="${workspace_loc:/greclipse-test1}"/>
</launchConfiguration>

This produces the same result with this single file groovy project with no other projects open and after a restart.

Comment by Bob Tiernay [ 04/Aug/11 ]

Verified that the original attached launch configuration works in Helios with 2.5.2.xx-20110725-1700-e36

Comment by Bob Tiernay [ 04/Aug/11 ]

Also verified the original attached launch configuration works in Helios with 2.5.2.xx-20110729-1700-e36. So it appears to only be an issue on Indigo Release Build id: 20110615-0604 with 2.5.2.xx-20110729-1700-e36

Comment by Bob Tiernay [ 04/Aug/11 ]

Also note that I have no problems with running scripts with Indigo Release Build id: 20110615-0604 with 2.5.2.xx-20110729-1700-e36 that don't contain a class definition. The launch configurations are identical as well (less the script file configuration)

Comment by Daniel Galán y Martins [ 17/Aug/11 ]

Hi, I have this problem using eclipse 3.7 Indigo (Build id: 20110615-0604), with a fresh installed groovy plugin. I run Ubuntu 11.04, Oracle JDK 1.6.0_25. Groovy Compiler 1.8.0.xx.20110628-1600-e37, the groovy pluginversions are added as screenshot (I was lazy).

I added a sample code fragment, that breaks when launching in eclipse (script and console), but does not when using the command line via groovy sandbox/Greeter.groovy.

package sandbox

class Greeter {

	 static void main(String[] args) {
		def mygreeting = "Hello World"
		println mygreeting
	}

}

I attached a project with launcher configuration, to provide best possible reproducibility.

Here is the complete stacktrace when run in console:

groovy> package sandbox 
groovy> class Greeter { 
groovy>      static void main(String[] args) { 
groovy>         def mygreeting = "Hello World" 
groovy>         println mygreeting 
groovy>     } 
groovy> } 
 
Exception thrown
17.08.2011 13:08:16 org.codehaus.groovy.runtime.StackTraceUtils sanitize
WARNUNG: Sanitizing stacktrace:
java.lang.AbstractMethodError
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:266)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:366)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1056)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174)
	at org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:763)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:957)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:542)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:520)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
	at groovy.lang.GroovyShell.run(GroovyShell.java:516)
	at groovy.lang.GroovyShell.run(GroovyShell.java:172)
	at groovy.lang.GroovyShell$run.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy:910)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:885)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:885)
	at groovy.lang.Closure.call(Closure.java:405)
	at groovy.lang.Closure.call(Closure.java:399)
	at groovy.lang.Closure.run(Closure.java:483)
	at java.lang.Thread.run(Thread.java:662)

java.lang.AbstractMethodError
Comment by Andrew Eisenberg [ 17/Aug/11 ]

Have you tried deleting the launcher and creating a new one?

Comment by Daniel Galán y Martins [ 17/Aug/11 ]

Yup - deleted, and new started (which creates a new launch configuration). Unfortunatly it didn't helped.

Comment by Andrew Eisenberg [ 17/Aug/11 ]

Open up the Preferences -> Groovy -> Compiler page. Are you using Groovy 1.7 or 1.8?

Your problem is that there is a compiler mismatch problem happening somewhere. We just need to find out what is causing it.

Comment by Daniel Galán y Martins [ 18/Aug/11 ]

Groovy Compiler 1.8.0.xx.20110628-1600-e37. But I tried the "Switch to 1.7" too, without success (even with 1.7 the problem occurs).

Comment by Andrew Eisenberg [ 18/Aug/11 ]

Let's try to get around the problem with your compiler switching for now. I know other people who have had a problem with compiler switching on recent builds and I have a fix for that, but the groovy-eclipse svn repo is closed for commits, so I can't create a build for that right now.

I'm guessing that you want to use version 1.8, so do this:

  1. shut down eclipse
  2. open the file ..../eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
  3. make a backup of this file.
  4. look for the two lines that start with org.codehaus.eclipse. There should be 2 entries, one for 1.7 and another for 1.8.
  5. Delete the 1.7 entry (or delete the 1.8 entry if you want to use 1.7)
  6. restart eclipse and you should be using 1.8 with no chance of switching back to 1.7 (without editing the bundles.info file).
  7. Full build of your project
  8. delete the old launch configuration
  9. Launch as a groovy script

Hopefully, this should get you launching again. If not, could you try launching as a Java application?

Comment by Bob Tiernay [ 18/Aug/11 ]

Okay, so I've been able to narrow the problem down while using "Run As > Groovy Console". When I capture the process via ps I get:

/usr/lib/jvm/java-6-sun-1.6.0.26/bin/java -Dgroovy.starter.conf=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37//conf/groovy-starter.conf -Dgroovy.home=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/ -Dfile.encoding=UTF-8 -classpath /local/btiernay/workspace/greclipse-test/bin:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/groovy-all-1.8.1.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/ivy-2.2.0.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/commons-cli-1.2.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/jline-0.9.94.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/servlet-api-2.4.jar:/local/btiernay/.groovy/greclipse/global_dsld_support:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/plugin_dsld_support/ org.codehaus.groovy.tools.GroovyStarter --classpath /local/btiernay/workspace/greclipse-test/src:/local/btiernay/workspace/greclipse-test/bin --main groovy.ui.Console /local/btiernay/workspace/greclipse-test/src/com/oanda/bi/groovy/ClassTest.groovy

This launches a groovyConsole which produces the same abstract method error. If I remove the following from the line, the problem goes away:

 -Dgroovy.starter.conf=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37//conf/groovy-starter.conf

The contents of this file is:

##############################################################################
##                                                                          ##
##  Groovy Classloading Configuration                                       ##
##                                                                          ##
##############################################################################

##
## $Revision: 9225 $ $Date: 2007-11-16 06:17:45 +1000 (Fri, 16 Nov 2007) $
##
## Note: do not add classes from java.lang here. No rt.jar and on some
##       platforms no tools.jar
##
## See http://groovy.codehaus.org/api/org/codehaus/groovy/tools/LoaderConfiguration.html
## for the file format

    # load required libraries
    load !{groovy.home}/lib/*.jar

    # load user specific libraries
    load !{user.home}/.groovy/lib/*.jar

    # tools.jar for ant tasks
    load ${tools.jar}
~                         

Is it possible that one of these jars, such as tools.jar, is messing something up?

Comment by Bob Tiernay [ 18/Aug/11 ]

Okay, so it looks as though it's the {{load !

{groovy.home}

/lib/*.jar}} statement.

Comment by Bob Tiernay [ 18/Aug/11 ]

Interestingly, if I create the following script:

println 1

in my groovy 1.8.1 groovyConsole, and inspect the AST, I get:

this.println(1)
public class script1313714377542 extends groovy.lang.Script { 

    public script1313714377542() {
    }

    public script1313714377542(groovy.lang.Binding context) {
        super.setBinding(context)
    }

    public static void main(java.lang.String[] args) {
        org.codehaus.groovy.runtime.InvokerHelper.runScript(script1313714377542, args)
    }

    public java.lang.Object run() {
        this.println(1)
    }

    public java.lang.Object this$dist$invoke$3(java.lang.String name, java.lang.Object args) {
        return this."$name"(* args )
    }

    public void this$dist$set$3(java.lang.String name, java.lang.Object value) {
        this ."$name" = value 
    }

    public java.lang.Object this$dist$get$3(java.lang.String name) {
        return this ."$name"
    }

}

When I perform the same operation with the greclipse groovyConsole I get:

import groovypp.concurrent.*
import java.util.concurrent.*

return this.println(1)
public class script1313714393418 extends groovy.lang.Script { 

    private static org.codehaus.groovy.reflection.ClassInfo $staticClassInfo 
    public static transient boolean __$stMC 
    public static long __timeStamp 
    public static long __timeStamp__239_neverHappen1313714393464 

    public script1313714393418() {
    }

    public script1313714393418(groovy.lang.Binding context) {
        super.setBinding(context)
    }

    public static void main(java.lang.String[] args) {
        org.codehaus.groovy.runtime.InvokerHelper.runScript(script1313714393418, args)
    }

    public java.lang.Object run() {
        return this.println(1)
    }

    public java.lang.Object this$dist$invoke$3(java.lang.String name, java.lang.Object args) {
        return this."$name"(* args )
    }

    public void this$dist$set$3(java.lang.String name, java.lang.Object value) {
        this ."$name" = value 
    }

    public java.lang.Object this$dist$get$3(java.lang.String name) {
        return this ."$name"
    }

    protected groovy.lang.MetaClass $getStaticMetaClass() {
    }

    static static { 
        __timeStamp__239_neverHappen1313714393464 = 0
        __timeStamp = 1313714393464
    }

}

Notice how this includes imports from groovy++. I'm not sure where those are coming from and they are not on the classpath.

Comment by Bob Tiernay [ 18/Aug/11 ]

Okay, so digging further I have discovered that removing /opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/groovypp-0.4.248_1.8.0.jar fixes the original problem specified in this issue. There are probably some global ast transformations that are getting applied here that shouldn't be.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

Thanks for digging into this. I was not aware that everything from groovy.home was automatically added to your script's runtime classpath. I was able to reproduce the little test you did with the groovy console.

We need to move all non-essential jars out of that folder into a new location where they will not conflict with running scripts.

I'm still not sure why I was not seeing the same problem that you were.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

Daniel, I think that you are having a different problem, but it may be worth trying anyway. Can you try moving your groovypp jar to a new folder?

Comment by Daniel Galán y Martins [ 19/Aug/11 ]

Andrew, thanks for your instructions, I performed them as you told, but the problem still remains.
I tried Bobs suggestion, and removed the groovypp-0.4.248_1.8.0.jar library, which seemed to work.
So I'm taking this workaround for now, hopping that it won't break to much other things, until there is an official bugfix release.
Thanks for your dedication on this topic!

Comment by Andrew Eisenberg [ 19/Aug/11 ]

That's good that it turned out to be the same issue. I will implement the fix to move the groovypp jar from the /lib folder to the /extras folder. More jars may be moved there in order for the default classpath of scripts to not get too messy.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

I am tentatively closing this issue since I committed the change for removing the groovypp jar from the classpath of scripts.

If you continue to have trouble executing scripts, please re-open.





[GRECLIPSE-1167] Compiler error appears/disappears when file repeatedly saved: "cannot be resolved. It is indirectly referenced from the required .class files" Created: 03/Aug/11  Updated: 18/Jan/12  Resolved: 17/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Aled Sage Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive compilation-bug.zip    
Testcase included: yes
Number of attachments : 1

 Description   

Steps to reproduce:

  1. Import the attached project
  2. Open HttpSensorAdapter.groovy
  3. Dirty the file and save (e.g. add white space)

It reports the error a compilation error on the file at line 1:

The type brooklyn.event.adapter.ValueProvider$1 cannot be resolved. It is indirectly referenced from the required .class files

In the problems view, it shows:

The project was not built since its build path is incomplete. Cannot find the class file for brooklyn.event.adapter.ValueProvider$1. Fix the build path then try building this project

Then:
4. Dirty the file again and save.
The compilation errors goes away.
5. Goto 3.
It repeats, with the compilation disappearing/reappearing alternately on each save of the file.


Below is the contents of the attached files:

src/brooklyn/event/adapter/HttpSensorAdapter.groovy
  package brooklyn.event.adapter

  public class HttpSensorAdapter {
  }

  public class Foo implements ValueProvider<String> {
      public String compute() {
          return null
      }
  }
src/brooklyn/event/adapter/ValueProvider.groovy

  package brooklyn.event.adapter
  
  public interface ValueProvider<T> {
  
      public T compute();
          
  }


 Comments   
Comment by Andrew Eisenberg [ 03/Aug/11 ]

Thanks for the test case. It is easy to reproduce.

Just a quick look confirmed my suspicion that this is a generics-related issue. If the type parameter on ValueProvider is removed, then things behave correctly.

Comment by Andy Clement [ 17/Oct/11 ]

This is a groovy bug: http://jira.codehaus.org/browse/GROOVY-5082 - similar to a few other issues, eclipse is picking up on any sillyness in the .class files groovy is producing.

In this case Groovy is incorrectly including references to types in the interface type which it then fails to create .class files for. Sometimes eclipse doesn't mind, but sometimes eclipse attempts to locate them (and expects to find them as the interface type named them). Using generics here is a trigger for eclipse to do the extra searching.

I've included my proposed groovy patch in groovy-eclipse.





[GRECLIPSE-1166] compareTo operator should support type inferencing Created: 02/Aug/11  Updated: 18/Aug/11  Resolved: 18/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The type of the following is not inferred:

(1 <=> 2).intValue()


 Comments   
Comment by Bob Tiernay [ 02/Aug/11 ]

Related is the following as well, which I'm putting here to prevent a proliferation of jira issues:

(1 < 2).booleanValue()
(1 > 2).booleanValue()
Comment by Andrew Eisenberg [ 18/Aug/11 ]

Hmmm...currently the types of all of these expressions are inferred to be String. Not right.

Comment by Andrew Eisenberg [ 18/Aug/11 ]

I fixed the three cases mentioned here and I also went through the list of groovy operators to make sure there aren't others that I am missing.

Here: http://groovy.codehaus.org/Operators

I added support for things like '.', '.@', '.&'. Regression tests are included.





[GRECLIPSE-1165] Type inferencing and content assist support for Spread-dot expressions Created: 01/Aug/11  Updated: 19/Aug/11  Resolved: 19/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following expressions should not be underlined in the editor and should be subject to content assist:

[1,2,3]*.intValue()
[x:1,y:2,z:3]*.getKey()
[x:1,y:2,z:3]*.getKey().toLowerCase()
[x:1,y:2,z:3]*.getValue().intValue()


 Comments   
Comment by Andrew Eisenberg [ 18/Aug/11 ]

These two variants:

[x:1,y:2,z:3]*.getKey().toLowerCase()
[x:1,y:2,z:3]*.getValue().intValue()

produce runtime errors.

The type of [x:1,y:2,z:3]*.getKey() is List<String>.

Comment by Andrew Eisenberg [ 18/Aug/11 ]

I think this is what you meant:

[x:1,y:2,z:3]*.key[0].toLowerCase() 
[x:1,y:2,z:3]*.value[0].intValue()
Comment by Andrew Eisenberg [ 19/Aug/11 ]

Now working. Unfortunately, the groovy svn repo is still closed for commits, so this is sitting in my workspace.





[GRECLIPSE-1164] Content assist for groovy.lang.Range literals Created: 01/Aug/11  Updated: 01/Sep/11  Resolved: 01/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Range literals do not get content assist suggestions and methods are underlined in the editor. For example

(1..10).getFrom()
(1..10).getTo()
(1..10).isReverse()


 Comments   
Comment by Andrew Eisenberg [ 01/Sep/11 ]

Fixed. The problem was that we were inferring them as lists, not as ranges. Fixed now with regression tests.





[GRECLIPSE-1162] Code-completion and highlight not working for boolean properties Created: 31/Jul/11  Updated: 07/Aug/11  Resolved: 06/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist, Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: D Gardner Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.7.1, Grails 1.3.7, Java 1.6.0


Number of attachments : 0

 Description   

I was logging some details of a org.codehaus.groovy.grails.commons.GrailsDomainClassProperty object and noticed problems with the auto-completion and syntax highlighting of boolean properties.

For example, I have a variable "p" of that type and I can auto-complete the property "p.name" based on the "String getName()" method and it is highlighted correctly. However, I cannot do the same for "p.association": the auto-completion does not suggest this property and it is not highlighted properly when I type it in. It is a valid property, of course; it is based on the "boolean isAssociation()" method.

I suspect that the auto-completion and syntax highlighting do not recognise property accessor methods that use the "isX/setX" naming convention for boolean properties. They only seem to recognise property accessor methods that use the "getX/setX" naming convention, which is not typically used for boolean properties.

There are a few extra subtleties. If there is an "isX method but no "setX" method, neither auto-completion nor syntax highlighting work. If there is a companion "setX" method, then auto-completion works, but syntax highlighting still does not work.



 Comments   
Comment by Andrew Eisenberg [ 06/Aug/11 ]

That's correct about isX not being recognized.

Comment by Andrew Eisenberg [ 06/Aug/11 ]

Part of the problem here is that we don't always know the type of the referenced variable when we are checking its name. This makes things difficult since 'is' is only appropriate for booleans.

Comment by Andrew Eisenberg [ 06/Aug/11 ]

OK. I think I have something that works. I just need to add a few tests.

Comment by Andrew Eisenberg [ 06/Aug/11 ]

Now I have the tests. Here is what I have working. In the following code, there is no underlining:

class O {
	booleam first
	booleam isSecond() { }	
}
O obj
obj.isFirst()
obj.second

Also, isFirst and second appear as proposals. Now, in this case, there is something maybe a little controversial, but I think it is OK:

In this code, the reference to second is not underlined even though this reference may be invalid. The thinking is that if someone prefixes a method with 'is' then it is highly likely to return a boolean even if it is not explicitly typed as such. However, the reference to {PisFirst}} is underlined. I'm thinking that it probably shouldn't be for exactly the same reasons.

class O {
	def first
	def isSecond() { }	
}
O obj
obj.isFirst()
obj.second

I'll think about this for a bit and commit soon.

Comment by Andrew Eisenberg [ 06/Aug/11 ]

I committed the fix even with the small inconsistency. I'll open a new bug to track it.

Comment by D Gardner [ 07/Aug/11 ]

Does it really matter if "isX" returns a boolean or not? I think that the only requirement is that "isX" should, like "getY", be assumed to return the value of a bean property without worrying much about the type of that property. There are probably plenty of examples of "getY" methods not returning values or not representing true bean properties, but we can all live with that.

Do you have an edge case in your tests to ignore names like "issueCommand" that also start with "is", or even names like "getterMethods", for that matter? Just checking.





[GRECLIPSE-1161] Groovy syntax highlighting does not work occasionally Created: 30/Jul/11  Updated: 17/Aug/11  Resolved: 17/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: D Gardner Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux/Kubuntu 10.10, Java 1.6.0_26, Spring IDE (STS) 2.7.1.201107082359-RELEASE, Groovy-Eclipse plugin 2.5.1.xx-20110627-1300-e36


Number of attachments : 0

 Description   

Occasionally, when I start STS or after using it for a while, syntax highlighting in the Groovy editor stops working fully. Only keywords and strings are highlighted, everything else reverts to blank and white. The only way to make it work again is to restart STS and hope it works properly the next time. I'm not sure if it's relevant, but the STS log is full of exception messages like this one:

!ENTRY org.eclipse.jdt.core 4 0 2011-07-30 14:35:07.444
!MESSAGE Code assist internal error
!STACK 0
java.lang.NullPointerException
        at org.codehaus.groovy.antlr.parser.GroovyLexer.require(GroovyLexer.java:300)
        at org.codehaus.groovy.antlr.parser.GroovyLexer.mSTRING_CTOR_END(GroovyLexer.java:2355)
        at org.codehaus.groovy.antlr.parser.GroovyLexer.mSTRING_LITERAL(GroovyLexer.java:1964)
        at org.codehaus.groovy.antlr.parser.GroovyLexer.nextToken(GroovyLexer.java:459)
        at org.codehaus.groovy.antlr.parser.GroovyLexer$1.nextToken(GroovyLexer.java:249)
        at org.eclipse.jdt.groovy.core.util.GroovyScanner.nextToken(GroovyScanner.java:59)
        at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyDocumentScanner.nextToken(GroovyDocumentScanner.java:119)
        at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyDocumentScanner.getTokensIncludingEOF(GroovyDocumentScanner.java: 105)
        at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyDocumentScanner.ensureScanned(GroovyDocumentScanner.java:96)
        at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyDocumentScanner.findTokenFrom(GroovyDocumentScanner.java:297)
        at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyDocumentScanner.getLastTokenBefore(GroovyDocumentScanner.java:340)
        at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyIndentationService.getTokenBefore(GroovyIndentationService.java:  419)
        at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyIndentationService.                                               computeIndentAfterNewline(GroovyIndentationService.java:204)
        at org.codehaus.groovy.eclipse.editor.GroovyAutoIndentStrategy.autoEditAfterNewline(GroovyAutoIndentStrategy.java:147)
        at org.codehaus.groovy.eclipse.editor.GroovyAutoIndentStrategy.customizeDocumentCommand(GroovyAutoIndentStrategy.java:61)
        at org.eclipse.jface.text.TextViewer.customizeDocumentCommand(TextViewer.java:3741)
        at org.eclipse.jface.text.TextViewer.handleVerifyEvent(TextViewer.java:3778)
        at org.eclipse.jface.text.source.projection.ProjectionViewer.handleVerifyEvent(ProjectionViewer.java:1277)
        at org.eclipse.jface.text.TextViewer$TextVerifyListener.verifyText(TextViewer.java:433)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:255)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267)
        at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1061)
        at org.eclipse.swt.custom.StyledText.modifyContent(StyledText.java:7140)
        at org.eclipse.swt.custom.StyledText.sendKeyEvent(StyledText.java:7986)
        at org.eclipse.swt.custom.StyledText.doContent(StyledText.java:2459)
        at org.eclipse.swt.custom.StyledText.handleKey(StyledText.java:5932)
        at org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5962)
        at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5656)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267)
        at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1294)
        at org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:730)
        at org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:2841)
        at org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:734)
        at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1743)
        at org.eclipse.swt.widgets.Control.windowProc(Control.java:4796)
        at org.eclipse.swt.widgets.Display.windowProc(Display.java:4360)
        at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
        at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8189)
        at org.eclipse.swt.widgets.Display.eventProc(Display.java:1238)
        at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
        at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2237)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3159)
        at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
        at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
        at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
        at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1384)

I'm not sure if that exception is related to the problem, but it is the only type of exception reported in the log since I started STS today.

I just restarted STS and Groovy syntax highlighting still wasn't working. I restarted it again and Groovy syntax highlighting was working again. The only difference was that I had selected a different editor. I have several files open in editors when I start my STS session. If I start with a Groovy editor selected (from when I last quit STS), syntax highlighting works; if I start with a GSP editor selected, syntax highlighting doesn't work when I switch to a Groovy editor. During all of these restarts, no new messages were added to the workspace log.



 Comments   
Comment by D Gardner [ 30/Jul/11 ]

Sorry, I forgot to mention that I have noticed this problem in every STS release from 2.5.1 to 2.7.1.

Also, to simplify things a bit more, I closed all editors before quitting STS. When I started STS again, if I first opened a GSP file and then a Groovy file, Groovy syntax highlighting was broken. If I opened a Groovy file first, syntax highlighting was OK. It doesn't appear to be an issue with the start-up of the whole workspace, then, just some conflict between these two editors and the order in which they are first used.

I'd add that above, but I can't figure out how to edit the descriptions of my own bugs (which would be handy, as I could change "blank and white" to "black and white", too).

Comment by Andrew Eisenberg [ 30/Jul/11 ]

I can reproduce this. Thanks for a detailed description of the problem.

Comment by D Gardner [ 31/Jul/11 ]

That's good to hear. Thank you for your quick attention. As I figured out yesterday how to avoid this problem, I can wait patiently for a fix. GRECLIPSE-1137 is a more regular annoyance for me, though.

Comment by Andrew Eisenberg [ 17/Aug/11 ]

Turns out that this was purely an STS issue. We had been incorrectly setting the property store for GSP syntax highlighting. The property store is the thing that (among other things) persists the color preferences for syntax highlighting. The property store is used to populate the colors and then these colors are cached until they are changed. Since we were using the wrong store, when asked to populate the colors, the store didn't know anything about them and so it just defaulted everything to black (which is cached and used in Groovy editors).

This is now changed in STS and things are working as expected.





[GRECLIPSE-1160] jdt patch 2.1.3.xx-20110729-1800-e37 error on project build Created: 30/Jul/11  Updated: 31/Jul/11  Resolved: 31/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andy Clement
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I started getting the following exception in the eclipse log after pulling the lastest dev release (jdt patch 2.1.3.xx-20110729-1800-e37):

!ENTRY org.eclipse.core.resources 4 75 2011-07-30 09:41:37.525
!MESSAGE Errors occurred during the build.
!SUBENTRY 1 org.eclipse.jdt.core 4 75 2011-07-30 09:41:37.525
!MESSAGE Errors running builder 'Java Builder' on project 'analysis'.
!STACK 0
java.lang.NullPointerException
	at org.codehaus.groovy.classgen.Verifier.correctToGenericsSpec(Verifier.java:1281)
	at org.codehaus.groovy.classgen.Verifier.equalParametersWithGenerics(Verifier.java:1306)
	at org.codehaus.groovy.classgen.Verifier.getCovariantImplementation(Verifier.java:1137)
	at org.codehaus.groovy.classgen.Verifier.storeMissingCovariantMethods(Verifier.java:1262)
	at org.codehaus.groovy.classgen.Verifier.addCovariantMethods(Verifier.java:1102)
	at org.codehaus.groovy.classgen.Verifier.addCovariantMethods(Verifier.java:1058)
	at org.codehaus.groovy.classgen.Verifier.visitClass(Verifier.java:183)
	at org.codehaus.groovy.control.CompilationUnit$6.call(CompilationUnit.java:779)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1106)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:587)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:565)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:542)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1501)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:831)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:662)

This occurs when a build is initiated. The error in the editor is:

Errors occurred during the build.
Errors running builder 'Java Builder' on project 'analysis'.
java.lang.NullPointerException


 Comments   
Comment by Andy Clement [ 30/Jul/11 ]

By any chance, can you come up with some example code that shows the issue? (or maybe share your project with me?)

Comment by Bob Tiernay [ 30/Jul/11 ]

Okay, was able to narrow it down to a project with a single class:

class Test extends PrintWriter {
    def print(obj) {
    }
}

Looks like this could be some sort of conflict with DGM methods perhaps? This is one of the things that changed since the last build. Andrew added some new type inferencing support.

Comment by Andy Clement [ 30/Jul/11 ]

I'm afraid that test program just gives me a regular error:

Groovy:The return type of java.lang.Object print(java.lang.Object) in Test is incompatible with void print(java.lang.Object) in java.io.PrintWriter

No NPE. I was assuming this problem appeared due to us upgrading to Groovy 1.8.1 (which we did yesterday) and we've inherited a problem of theirs. Perhaps one of the other projects in your workspace is interfering? You can determine this by closing all the other projects and restarting eclipse, does the bug still appear for this snippet.

Comment by Bob Tiernay [ 31/Jul/11 ]

Okay, after closing all projects and restarting my workspace, this issue goes away. Perhaps I didn't restart after installing the latest plugin, but I'm pretty sure I did Also, I had 2 versions of groovy on the classpath since I'm building with m2eclipse and I didn't update my pom to 1.8.1. Sorry for the confusion. Recommending this issue be closed.

Comment by Andy Clement [ 31/Jul/11 ]

thanks for letting me know. If you see it again, please reopen this issue.





[GRECLIPSE-1159] Result of match operator (=~, ==~) expressions should support type inferencing Created: 28/Jul/11  Updated: 04/Aug/11  Resolved: 29/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following should support type inferencing:

("" =~ /pattern/).hasGroup()
("" ==~ /pattern/).booleanValue()


 Comments   
Comment by Bob Tiernay [ 28/Jul/11 ]

Please disregard the second example as this works

Comment by Andrew Eisenberg [ 29/Jul/11 ]

Actually, the second expression works by accident. The type of the expression is String (should be boolean). String has a booleanValue method as well.

Comment by Andrew Eisenberg [ 29/Jul/11 ]

Oops. I was wrong. The second example was indeed working properly (booleanValue is not a method on String).

Anyway, the first one is fixed now as well.

Comment by Bob Tiernay [ 04/Aug/11 ]

I notice this still isn't working in 2.5.2.xx-20110729-1800-e37. Should it?

Comment by Andrew Eisenberg [ 04/Aug/11 ]

A build hasn't gone through in the past few days. It is working with the code as it is in version control, but there is not yet a snapshot available.





[GRECLIPSE-1158] Add content assist for DateGroovyMethods, EncodingGroovyMethods, SwingGroovyMethods, SqlGroovyMethods, XmlGroovyMethods Created: 28/Jul/11  Updated: 29/Sep/11  Resolved: 29/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

DateGroovyMethods, DefaultGroovyStaticMethods, EncodingGroovyMethods, ProcessGroovyMethods, SwingGroovyMethods, XmlGroovyMethods currently aren't supported in content assist. Here are a few examples:

Date date = new Date()
date.putAt( 1, 2 )
date.toCalendar()
date.set([1:1])
date.next()
date.previous()
date.plus(1)
date.minus(1)
date.format("yyyy")
date.getDateString()
date.getTimeString()
date.getDateTimeString()
date.clearTime()

Calendar calendar = Calendar.getInstance()
calendar.updated([1:1])
calendar.clearTime()
calendar.format("yyyy")

Byte[] data =  [] as Byte[]
data.encodeBase64()
data.encodeBase64(true)
"DEADBEEF".decodeBase64()


ResultSet rs = null
rs?.toRowResult()

GroovyResultSet grs = null
grs.asBoolean()

Date date = new Date()
date.toTimestamp()

ResultSetMetaData rsmd = null
rsmd?.iterator()



 Comments   
Comment by Andrew Eisenberg [ 29/Jul/11 ]

Fixed.

Comment by Andrew Eisenberg [ 29/Jul/11 ]

One issue is that some of these methods are duplicated in DGM and in other in another XGroovyMethods class. The variant in DGM is deprecated, so I am not too worried about it, but it does mean that the proposal will appear twice in content assist.

Comment by Bob Tiernay [ 29/Jul/11 ]

That's fine with me However, is there a way to make the suggest priority higher for the more specific and non-deprecated methods? By specific I mean XGroovyMethods not in DGM?

Comment by Bob Tiernay [ 29/Jul/11 ]

Also, I did a cursory check of ProcessGroovyMethods. They appeared to be handled already. Is that your understanding?

Comment by Andrew Eisenberg [ 30/Jul/11 ]

You are probably already seeing them because the DGM variant of these methods are being proposed instead of the PGM methods. The DGM variants are deprecated. I might be able to simply ignore the deprecated DGM methods.

Comment by Andrew Eisenberg [ 30/Jul/11 ]

Re-opening until I can look at removing deprecated DGMs.

Comment by Bob Tiernay [ 31/Jul/11 ]

For completeness, perhaps we should also consider the org.codehaus.groovy.vmplugin.* classes such as PluginStaticGroovyMethods and PluginDefaultGroovyMethods.

Comment by Andrew Eisenberg [ 02/Aug/11 ]

It looks like the deprecated DGMs only exist in 1.7. They have been removed in 1.8, so I don't need to handle them.

Also, PluginDefaultGroovyMethods and PluginStaticDefaultGroovyMethods now available.

Comment by Andrew Eisenberg [ 29/Sep/11 ]

Resolving this bug since there is not much I can do about deprecated DGM methods. At this point in the inferencing process, the deprecated bit has not been set.





[GRECLIPSE-1157] Upgrade groovy-eclipse to groovy 1.8.1 Created: 28/Jul/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: New Feature Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 08/Sep/11 ]

done





[GRECLIPSE-1156] Upgrade groovy-eclipse to the Eclipse Java 7 compiler Created: 28/Jul/11  Updated: 26/Sep/11  Resolved: 26/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: New Feature Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Issue GRECLIPSE-1134 is related but I wanted a clean Jira to track doing this upgrade.



 Comments   
Comment by Mauro Molinari [ 26/Sep/11 ]

Issue GRECLIPSE-1177 is marked as a duplicate of this.
I'm using Indigo SR-1 (3.7.1) with GRECLIPSE 2.5.2.xx-20110921-1600-e37 downloaded from http://dist.springsource.org/release/GRECLIPSE/e3.7/ and whenever I try to open a Groovy file I have the following exception and the editor does not show:

java.lang.NoClassDefFoundError: org/codehaus/groovy/eclipse/refactoring/formatter/GroovyIndentationService
at org.codehaus.groovy.eclipse.editor.GroovyAutoIndentStrategy.<init>(GroovyAutoIndentStrategy.java:50)
at org.codehaus.groovy.eclipse.editor.GroovyConfiguration.getAutoEditStrategies(GroovyConfiguration.java:172)
at org.eclipse.jface.text.source.SourceViewer.configure(SourceViewer.java:502)
at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.configure(JavaSourceViewer.java:230)
at org.eclipse.ui.texteditor.AbstractTextEditor.createPartControl(AbstractTextEditor.java:3407)
at org.eclipse.ui.texteditor.StatusTextEditor.createPartControl(StatusTextEditor.java:54)
at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.createPartControl(AbstractDecoratedTextEditor.java:440)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.createPartControl(JavaEditor.java:3098)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.createPartControl(CompilationUnitEditor.java:1505)
at org.codehaus.groovy.eclipse.editor.GroovyEditor.createPartControl(GroovyEditor.java:960)
at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:670)
at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:289)
at org.eclipse.ui.internal.EditorManager.findEditor(EditorManager.java:424)
at org.eclipse.ui.internal.EditorManager.findEditor(EditorManager.java:402)
at org.eclipse.ui.internal.WorkbenchPage.findEditor(WorkbenchPage.java:2178)
at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.isOpenInEditor(EditorUtility.java:130)
at org.eclipse.jdt.internal.ui.navigator.JavaFileLinkHelper.activateEditor(JavaFileLinkHelper.java:38)
at org.eclipse.ui.internal.navigator.actions.LinkEditorAction$2.run(LinkEditorAction.java:78)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.navigator.actions.LinkEditorAction$1.runInUIThread(LinkEditorAction.java:76)
at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)

I'm blocked.
Please note that I'm NOT using Java 7, I'm working on a project which is using Java 6.
What should I do?

Comment by Andy Clement [ 26/Sep/11 ]

You need a dev build from Friday 23rd or later. Only those are installable on Eclipse 3.7.1. It doesnt matter whether you are using java6 or java7, only those versions (or later) of groovy-eclipse are compatible with Eclipse 3.7.1





[GRECLIPSE-1155] DGM eachPermutation should infer permutation type Created: 27/Jul/11  Updated: 29/Jul/11  Resolved: 29/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following does not infer the type of it in the closure to be List<Integer>:

[1, 2].eachPermutation { it[0].intValue() }


 Comments   
Comment by Andrew Eisenberg [ 29/Jul/11 ]

fixed.





[GRECLIPSE-1154] Sort should support type inferencing on its arguments Created: 27/Jul/11  Updated: 29/Jul/11  Resolved: 29/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following expression does not infer the type of a and b to be integer:

[1, 2].sort { a, b -> a.intValue() <=> b.intValue() }


 Comments   
Comment by Andrew Eisenberg [ 29/Jul/11 ]

Fixed.





[GRECLIPSE-1153] Content assist does not suggest DGM collectEntries Created: 27/Jul/11  Updated: 27/Jul/11  Resolved: 27/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Content assist does not suggest collectEntries below:

[x: 1].collectEntries { key, value -> [value, key] } 


 Comments   
Comment by Andrew Eisenberg [ 27/Jul/11 ]

Fix committed with regression tests.





[GRECLIPSE-1152] Dependency on wrong m2eclipse in eclipse 3.7 Created: 26/Jul/11  Updated: 07/Sep/11  Resolved: 07/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Bogdan Calmac Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse 3.7


Number of attachments : 0

 Description   

I have recently upgraded to eclipse 3.7 and I tried to install the "Groovy Eclipse M2E Integration" from http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7. However it failed with the error below. M2Eclipse comes bundled with eclipse 3.7 and the package name changed from org.maven.ide.eclipse to org.eclipse.m2e. The GRECLIPSE dependency must be updated accordingly.

Cannot complete the install because one or more required items could not be found.
Software being installed: Groovy-Eclipse M2E integration 1.0.0.201106101132 (org.codehaus.groovy.m2eclipse.feature.group 1.0.0.201106101132)
Missing requirement: Groovy-Eclipse M2E integration 1.0.0.201106101132 (org.codehaus.groovy.m2eclipse.feature.group 1.0.0.201106101132) requires 'org.maven.ide.eclipse 0.0.0' but it could not be found



 Comments   
Comment by Andrew Eisenberg [ 07/Sep/11 ]

See the latest snapshot build. There is now a new m2e configurator for Groovy-Eclipse (v2.5.2). You can install that and things should work for you. Do not install v1.0.0. That is only for m2e pre1.0.

For more information, see:
http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+compiler+plugin+for+Maven





[GRECLIPSE-1149] Enhanced debugger variables view support for closures Created: 25/Jul/11  Updated: 04/Dec/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File Show static variables.jpg     JPEG File variables view.jpg    
Number of attachments : 2

 Description   

In the following script, staticField, instanceField and localVariable should be visible in the debugger's variables view if a break point is positioned inside closure

new Type().method()

class Type {
    static staticField = 1
    
    def instanceField = 2

    def method() {
        def localVariable = 3

        def closure = { 
            println staticField 
            println instanceField 
            println localVariable 
        }

        closure()
    }
}

I realize this might be very difficult or impossible to do while reusing the existing JDT code but it is definitely something that will add tremendous value as closures are at the core of most things groovy. This is one of the biggest complaints I hear about using the debugger with groovy.



 Comments   
Comment by Andrew Eisenberg [ 29/Jul/11 ]

Use this to see static variables. I usually keep it off when debugging with groovy since it creates so many synthetic statics that appear, but add no value.

Comment by Andrew Eisenberg [ 29/Jul/11 ]

I have no problem finding these variables in the variables view. Maybe it's a little confusing that you have to look inside the delegate field to find instance field.

Comment by Andrew Eisenberg [ 29/Jul/11 ]

Are you seeing something different?

Also, I don't know if you are aware, but STS allows the use of the expressions and display views for evaluating groovy code (using groovy syntax).

Comment by Bob Tiernay [ 29/Jul/11 ]

Okay, user error

But, I did notice some groovy internals in there (static variables callsites, etc.). Is it possible to filter those out? Also, is it possible to get targets of the {{Reference}}s instead of the references themselves?

Comment by Andrew Eisenberg [ 28/Sep/11 ]

In the Variables view, there is a drop-down in the upper right corner. In there, you can choose the things that are filtered. I think this is sufficient. If not, please raise a new bug and describe what is still visible that you think should not be.

Comment by Bob Tiernay [ 04/Dec/11 ]

So, I have been thinking about this issue a little bit. Is it possible to make delegate fields / variables directly available in the variables view when the current stack frame is the closure body? It is very disruptive to have to open the delegate variable and search for these. This would greatly aid in developer debugging productivity due to the ubiquitous nature of closures.





[GRECLIPSE-1148] inject could support type inferencing on its accumulation closure argument Created: 25/Jul/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following expression, i could be inferred to be an int.

[1, 2].inject(0) { i, value -> i.intValue() + value.intValue() }


 Comments   
Comment by Andrew Eisenberg [ 25/Jul/11 ]

Fixed with regression tests.





[GRECLIPSE-1146] unique should support type inferencing on the second closure argument Created: 25/Jul/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following expression, b is not inferred to be an it:

[1, 2].unique { a, b -> a.intValue() <=> b.intValue() }


 Comments   
Comment by Andrew Eisenberg [ 25/Jul/11 ]

Fixed with regression tests.





[GRECLIPSE-1145] eachWithIndex could support type inferencing on index argument Created: 25/Jul/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the following expression, index could be inferred to be an int:

[1, 2].eachWithIndex { it, i -> it.intValue() + i.intValue() }


 Comments   
Comment by Andrew Eisenberg [ 25/Jul/11 ]

Fixed with regression tests.





[GRECLIPSE-1144] on String.class.getPackage(), the "getPackage" string is underlined Created: 25/Jul/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Mitko Kolev Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7


Testcase included: yes
Number of attachments : 0

 Description   

On

String.class.getPackage()

getPackage is underlined, although this is a legal Groovy/Java syntax. Of course this happens with classes other than String.



 Comments   
Comment by Andrew Eisenberg [ 25/Jul/11 ]

Fixed with regression tests.





[GRECLIPSE-1143] Type inference support for DGM methods Created: 24/Jul/11  Updated: 29/Sep/11  Resolved: 29/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File DefaultGroovyMethodsTestGenerator.groovy     File DefaultGroovyMethodsTestGenerator.groovy    
Number of attachments : 2

 Description   

The following snippets do not recognize the static type of the lists in side the supplied closures:

[1, 2].countBy { it.intValue() }
[1, 2].count { it.intValue() } 


 Comments   
Comment by Bob Tiernay [ 24/Jul/11 ]

Also, the following also does not infer the type of list inside the closure:

[1, 2].findResult { it.intValue() }
Comment by Bob Tiernay [ 24/Jul/11 ]

Also, the following does not infer the type of list inside the closure:

[1, 2].any { it.intValue() }
Comment by Bob Tiernay [ 25/Jul/11 ]

A couple more

[1, 2].grep { it.intValue() } 
[1, 2].split { it.intValue() }
Comment by Bob Tiernay [ 25/Jul/11 ]

And

[1, 2].removeAll { it.intValue() }
[1, 2].retainAll { it.intValue() }
Comment by Bob Tiernay [ 25/Jul/11 ]

And

[1, 2].inject(0) { i, value -> i.intValue() + value.intValue() }
Comment by Bob Tiernay [ 25/Jul/11 ]

And

[1, 2].sum { it.intValue() }
Comment by Andrew Eisenberg [ 25/Jul/11 ]

Fixed with regression tests.

Comment by Bob Tiernay [ 26/Jul/11 ]

It seems as though any still has issues:

[1, 2].any { it.intValue() }
Comment by Bob Tiernay [ 27/Jul/11 ]

The following methods don't infer types as well:

[1, 2].findIndexOf { it.intValue() }
[1, 2].findIndexOf(1) { it.intValue() }
[1, 2].findIndexValues { it.intValue() }
[1, 2].findIndexValues(1) { it.intValue() }
[1, 2].findLastIndexOf { it.intValue() }
[1, 2].findLastIndexOf(1) { it.intValue() }
[1, 2].collectAll { it.intValue() }
[1, 2].min { it.intValue()  }
[1, 2].max { it.intValue()  }
Comment by Andrew Eisenberg [ 27/Jul/11 ]

Thanks for being so thorough about this. I'll get to it tomorrow.

Comment by Bob Tiernay [ 28/Jul/11 ]

And some more:

1.identity { it.intValue() }
[1, 2].flatten { it.intValue() }
1.times { it.intValue() }
1.upto(2 ) { it.intValue() }
2.downto(1 ) { it.intValue() }
1.step( 1, 2 ) { it.intValue() }
new File("test").withObjectOutputStream { it.close() }
new File("test").withObjectInputStream { it.close() }
"".eachLine { it.toUpperCase() }
"".eachLine(0) { it.toUpperCase() }
new File("test").eachLine { it.toUpperCase() }
new File("test").eachLine("UTF8") { it.toUpperCase() }
"".splitEachLine("test") { it.toUpperCase() }
"".splitEachLine(~/test/) { it.toUpperCase() }
new File(".").eachFile { it.getName() }
new File(".").eachDir { it.getName() }
new File(".").eachFileRecurse(null) { it.getName() }
new File(".").eachFileRecurse() { it.getName() }
new File(".").eachDirRecurse() { it.getName() }
new File(".").traverse() { it.getName() }
new File(".").traverse([:]) { it.getName() }

Is there anyway to automate this?

Comment by Bob Tiernay [ 29/Jul/11 ]

Groovy script that will generate a set of type inference tests for DGM to stdout

Comment by Bob Tiernay [ 29/Jul/11 ]

Slightly enhanced to handle more argument types

Comment by Andrew Eisenberg [ 29/Jul/11 ]

Thanks for the script. It does show all the methods that we need to handle. However, as far as I can tell there is no way of automating this discovery in the IDE. In the static type information of the closure parameter of the DGM, the heuristic is simple: the parameter type is the same type as self, or if self is a collection, then extract the type parameter of the collection and look at that. But there are also special cases, such as eachWithIndex that take an extra argument and other methods, like each that depend also on the number of closure arguments.

Adding new rules is not complicated, but there is no way of determining what the special cases are without hard-coding them.

Comment by Andrew Eisenberg [ 29/Jul/11 ]

Fixed, again.

Comment by Bob Tiernay [ 09/Aug/11 ]

There still seems to be some issues with the 2.1.3.xx-20110808-1500-e37 release in this regard:


// Type inference test of public static java.util.Map$Entry org.codehaus.groovy.runtime.DefaultGroovyMethods.min(java.util.Map,groovy.lang.Closure)
[key:1].min { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.min(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).min { it.intValue() }

// Type inference test of public static java.util.Map$Entry org.codehaus.groovy.runtime.DefaultGroovyMethods.max(java.util.Map,groovy.lang.Closure)
[key:1].max { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.max(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).max { it.intValue() }

// Type inference test of public static java.lang.Number org.codehaus.groovy.runtime.DefaultGroovyMethods.count(java.util.Map,groovy.lang.Closure)
[key:1].count { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Number org.codehaus.groovy.runtime.DefaultGroovyMethods.count(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).count { it.intValue() }

// Type inference test of public static java.lang.String org.codehaus.groovy.runtime.DefaultGroovyMethods.replaceAll(java.lang.String,java.lang.String,groovy.lang.Closure)
"".replaceAll("") { it.toLowerCase() }

// Type inference test of public static java.lang.String org.codehaus.groovy.runtime.DefaultGroovyMethods.replaceAll(java.lang.String,java.util.regex.Pattern,groovy.lang.Closure)
"".replaceAll(~/test/) { it.toLowerCase() }

// Type inference test of public static java.lang.String org.codehaus.groovy.runtime.DefaultGroovyMethods.replaceFirst(java.lang.String,java.lang.String,groovy.lang.Closure)
"".replaceFirst("") { it.toLowerCase() }

// Type inference test of public static java.lang.String org.codehaus.groovy.runtime.DefaultGroovyMethods.replaceFirst(java.lang.String,java.util.regex.Pattern,groovy.lang.Closure)
"".replaceFirst(~/test/) { it.toLowerCase() }

// Type inference test of public static java.util.Map$Entry org.codehaus.groovy.runtime.DefaultGroovyMethods.find(java.util.Map,groovy.lang.Closure)
[key:1].find { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.sort(java.util.Map,groovy.lang.Closure)
[key:1].sort { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Object[] org.codehaus.groovy.runtime.DefaultGroovyMethods.sort(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).sort { it.intValue() }

// Type inference test of public static java.lang.Object[] org.codehaus.groovy.runtime.DefaultGroovyMethods.sort(java.lang.Object[],boolean,groovy.lang.Closure)
([1] as Object[]).sort(true) { it.intValue() }

// Type inference test of public static boolean org.codehaus.groovy.runtime.DefaultGroovyMethods.removeAll(java.util.Collection,groovy.lang.Closure)
[1].removeAll { it.intValue() }

// Type inference test of public static boolean org.codehaus.groovy.runtime.DefaultGroovyMethods.retainAll(java.util.Collection,groovy.lang.Closure)
[1].retainAll { it.intValue() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.addShutdownHook(java.lang.Object,groovy.lang.Closure)
1.addShutdownHook { it.intValue() }

// Type inference test of public static java.net.Socket org.codehaus.groovy.runtime.DefaultGroovyMethods.accept(java.net.ServerSocket,groovy.lang.Closure) throws java.io.IOException
new ServerSocket().accept { it.getPort() }

// Type inference test of public static java.net.Socket org.codehaus.groovy.runtime.DefaultGroovyMethods.accept(java.net.ServerSocket,boolean,groovy.lang.Closure) throws java.io.IOException
new ServerSocket().accept(true) { it.getPort() }

// Type inference test of public static groovy.lang.MetaClass org.codehaus.groovy.runtime.DefaultGroovyMethods.metaClass(java.lang.Class,groovy.lang.Closure)
Integer.metaClass { methods }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.with(java.lang.Object,groovy.lang.Closure)
1.with { it.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.use(java.lang.Object,java.lang.Class,groovy.lang.Closure)
1.use(Integer) { it.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.use(java.lang.Object,java.util.List,groovy.lang.Closure)
1.use([1]) { it.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.eachWithIndex(java.util.Map,groovy.lang.Closure)
[key:1].eachWithIndex { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.reverseEach(java.util.Map,groovy.lang.Closure)
[key:1].reverseEach { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Object[] org.codehaus.groovy.runtime.DefaultGroovyMethods.reverseEach(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).reverseEach { it.intValue() }

// Type inference test of public static boolean org.codehaus.groovy.runtime.DefaultGroovyMethods.every(java.util.Map,groovy.lang.Closure)
[key:1].every { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static boolean org.codehaus.groovy.runtime.DefaultGroovyMethods.any(java.util.Map,groovy.lang.Closure)
[key:1].any { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.util.List org.codehaus.groovy.runtime.DefaultGroovyMethods.collectNested(java.util.Collection,groovy.lang.Closure)
[1].collectNested { it.intValue() }

// Type inference test of public static java.util.Collection org.codehaus.groovy.runtime.DefaultGroovyMethods.collectNested(java.util.Collection,java.util.Collection,groovy.lang.Closure)
[1].collectNested([1]) { it.intValue() }

// Type inference test of public static java.util.Collection org.codehaus.groovy.runtime.DefaultGroovyMethods.collectMany(java.util.Collection,groovy.lang.Closure)
[1].collectMany { it.intValue() }

// Type inference test of public static java.util.Collection org.codehaus.groovy.runtime.DefaultGroovyMethods.collectMany(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).collectMany { it.intValue() }

// Type inference test of public static java.util.Collection org.codehaus.groovy.runtime.DefaultGroovyMethods.collectMany(java.util.Iterator,groovy.lang.Closure)
[1].iterator().collectMany { it.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.collectEntries(java.lang.Object[],java.util.Map,groovy.lang.Closure)
([1] as Object[]).collectEntries([key:1]) { it.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.collectEntries(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).collectEntries { it.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.findResult(java.util.Map,java.lang.Object,groovy.lang.Closure)
[key:1].findResult(1) { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.findResult(java.util.Map,groovy.lang.Closure)
[key:1].findResult { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.util.Collection org.codehaus.groovy.runtime.DefaultGroovyMethods.findResults(java.util.Collection,groovy.lang.Closure)
[1].findResults { it.intValue() }

// Type inference test of public static java.util.Collection org.codehaus.groovy.runtime.DefaultGroovyMethods.findResults(java.util.Map,groovy.lang.Closure)
[key:1].findResults { it.getKey().toUpperCase() + it.getValue().intValue() }
[key:1].findResults { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.findAll(java.util.Map,groovy.lang.Closure)
[key:1].findAll { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.groupBy(java.util.Map,groovy.lang.Closure)
[key:1].groupBy { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.countBy(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).countBy { it.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.countBy(java.util.Map,groovy.lang.Closure)
[key:1].countBy { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.groupEntriesBy(java.util.Map,groovy.lang.Closure)
[key:1].groupEntriesBy { it.getKey().toUpperCase() + it.getValue().intValue() }
[key:1].groupEntriesBy { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.inject(java.util.Map,java.lang.Object,groovy.lang.Closure)
[key:1].inject(1) { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.inject(java.lang.Object[],java.lang.Object,groovy.lang.Closure)
([1] as Object[]).inject(1) { value, item -> value.intValue() + item.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.sum(java.lang.Object[],groovy.lang.Closure)
([1] as Object[]).sum { it.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.sum(java.lang.Object[],java.lang.Object,groovy.lang.Closure)
([1] as Object[]).sum(1) { it.intValue() }

// Type inference test of public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.withDefault(java.util.Map,groovy.lang.Closure)
[key:1].withDefault { it.getKey().toUpperCase() + it.getValue().intValue() }
[key:1].withDefault { key, value -> key.toUpperCase() + value.intValue() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withStream(java.io.OutputStream,groovy.lang.Closure) throws java.io.IOException
new FileOutputStream(new File("test")).withStream { it.write(1) }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachObject(java.io.File,groovy.lang.Closure) throws java.io.IOException,java.lang.ClassNotFoundException
new File("test").eachObject { it.getName() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachObject(java.io.ObjectInputStream,groovy.lang.Closure) throws java.io.IOException,java.lang.ClassNotFoundException
new ObjectInputStream(new FileInputStream("test")).eachObject { it.read() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachFileMatch(java.io.File,groovy.io.FileType,java.lang.Object,groovy.lang.Closure) throws java.io.FileNotFoundException,java.lang.IllegalArgumentException
new File("test").eachFileMatch(FileType.FILES, 1) { it.getName() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachFileMatch(java.io.File,java.lang.Object,groovy.lang.Closure) throws java.io.FileNotFoundException,java.lang.IllegalArgumentException
new File("test").eachFileMatch(1) { it.getName() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachDirMatch(java.io.File,java.lang.Object,groovy.lang.Closure) throws java.io.FileNotFoundException,java.lang.IllegalArgumentException
new File("test").eachDirMatch(1) { it.getName() }

// Type inference test of public static java.util.TimerTask org.codehaus.groovy.runtime.DefaultGroovyMethods.runAfter(java.util.Timer,int,groovy.lang.Closure)
new Timer().runAfter(1) new Timer()

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withReader(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").withReader { it.reset() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withReader(java.io.File,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new File("test").withReader("") { it.reset()}

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withReader(java.io.Reader,groovy.lang.Closure) throws java.io.IOException
new FileReader(new File("test")).withReader { it.reset() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withReader(java.net.URL,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").withReader { it.reset() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withReader(java.net.URL,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").withReader("") { it.reset() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withReader(java.io.InputStream,groovy.lang.Closure) throws java.io.IOException
new FileInputStream(new File("test")).withReader { it.reset() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withReader(java.io.InputStream,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new FileInputStream(new File("test")).withReader("") { it.reset() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withOutputStream(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").withOutputStream { it.flush() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withInputStream(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").withInputStream { it.available() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withInputStream(java.net.URL,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").withInputStream { it.available() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withDataOutputStream(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").withDataOutputStream { it.flush() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withDataInputStream(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").withDataInputStream { it.readUTF() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withWriter(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").withWriter { it.getName() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withWriter(java.io.File,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new File("test").withWriter("") { it.getName() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withWriter(java.io.Writer,groovy.lang.Closure) throws java.io.IOException
new FileWriter(new File("test")).withWriter { it.write(1) }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withWriter(java.io.OutputStream,groovy.lang.Closure) throws java.io.IOException
new FileOutputStream(new File("test")).withWriter { it.write(1) }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withWriter(java.io.OutputStream,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new FileOutputStream(new File("test")).withWriter("") { it.write(1) }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withWriterAppend(java.io.File,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new File("test").withWriterAppend("") { it.write(1) }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withWriterAppend(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").withWriterAppend { it.write(1) }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withPrintWriter(java.io.Writer,groovy.lang.Closure) throws java.io.IOException
new FileWriter(new File("test")).withPrintWriter { it.write(1) }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachByte(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").eachByte { it.getName() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachByte(java.io.File,int,groovy.lang.Closure) throws java.io.IOException
new File("test").eachByte(1) { it.getName() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachByte(java.lang.Byte[],groovy.lang.Closure)
([1] as Byte[]).eachByte { buffer, bytesRead -> buffer.size() + bytesRead.intValue() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachByte(byte[],groovy.lang.Closure)
([1] as byte[]).eachByte {buffer, bytesRead -> buffer.size() + bytesRead.intValue() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachByte(java.io.InputStream,groovy.lang.Closure) throws java.io.IOException
new FileInputStream(new File("test")).eachByte { buffer, bytesRead -> buffer.size() + bytesRead.intValue() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachByte(java.io.InputStream,int,groovy.lang.Closure) throws java.io.IOException
new FileInputStream(new File("test")).eachByte(1) { buffer, bytesRead -> buffer.size() + bytesRead.intValue() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachByte(java.net.URL,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").eachByte { buffer, bytesRead -> buffer.size() + bytesRead.intValue() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.eachByte(java.net.URL,int,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").eachByte(1) { buffer, bytesRead -> buffer.size() + bytesRead.intValue() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.transformChar(java.io.Reader,java.io.Writer,groovy.lang.Closure) throws java.io.IOException
new FileReader(new File("test")).transformChar(new FileWriter(new File("test"))) { it.toUpperCase() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.transformLine(java.io.Reader,java.io.Writer,groovy.lang.Closure) throws java.io.IOException
new FileReader(new File("test")).transformLine(new FileWriter(new File("test"))) { it.toUpperCase() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.Reader,java.io.Writer,groovy.lang.Closure) throws java.io.IOException
new FileReader(new File("test")).filterLine(new FileWriter(new File("test"))) { it.toUpperCase() }

// Type inference test of public static groovy.lang.Writable org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.File,groovy.lang.Closure) throws java.io.IOException
new File("test").filterLine { it.toUpperCase() }

// Type inference test of public static groovy.lang.Writable org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.File,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new File("test").filterLine("") { it.toUpperCase() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.File,java.io.Writer,groovy.lang.Closure) throws java.io.IOException
new File("test").filterLine(new FileWriter(new File("test"))) { it.toUpperCase() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.File,java.io.Writer,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new File("test").filterLine(new FileWriter(new File("test")), "") { it.toUpperCase() }

// Type inference test of public static groovy.lang.Writable org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.Reader,groovy.lang.Closure)
new FileReader(new File("test")).filterLine { it.toUpperCase() }

// Type inference test of public static groovy.lang.Writable org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.InputStream,groovy.lang.Closure)
new FileInputStream(new File("test")).filterLine { it.toUpperCase() }

// Type inference test of public static groovy.lang.Writable org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.InputStream,java.lang.String,groovy.lang.Closure) throws java.io.UnsupportedEncodingException
new FileInputStream(new File("test")).filterLine("") { it.toUpperCase() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.InputStream,java.io.Writer,groovy.lang.Closure) throws java.io.IOException
new FileInputStream(new File("test")).filterLine(new FileWriter(new File("test"))) { it.toUpperCase() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.io.InputStream,java.io.Writer,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new FileInputStream(new File("test")).filterLine(new FileWriter(new File("test")), "") { it.toUpperCase() }

// Type inference test of public static groovy.lang.Writable org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.net.URL,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").filterLine { it.toUpperCase() }

// Type inference test of public static groovy.lang.Writable org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.net.URL,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").filterLine("") { it.toUpperCase() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.net.URL,java.io.Writer,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").filterLine(new FileWriter(new File("test"))) { it.toUpperCase() }

// Type inference test of public static void org.codehaus.groovy.runtime.DefaultGroovyMethods.filterLine(java.net.URL,java.io.Writer,java.lang.String,groovy.lang.Closure) throws java.io.IOException
new URL("http://www.google.com").filterLine(new FileWriter(new File("test")), "") { it.toUpperCase() }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withStreams(java.net.Socket,groovy.lang.Closure) throws java.io.IOException
new Socket().withStreams { is, os -> is.read(); os.write(1) }

// Type inference test of public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.withObjectStreams(java.net.Socket,groovy.lang.Closure) throws java.io.IOException
new Socket().withObjectStreams { is, os -> is.read(); os.write(1) }

// Type inference test of public static java.lang.String org.codehaus.groovy.runtime.DefaultGroovyMethods.eachMatch(java.lang.String,java.lang.String,groovy.lang.Closure)
"".eachMatch("") { it.toLowerCase() }

// Type inference test of public static java.lang.String org.codehaus.groovy.runtime.DefaultGroovyMethods.eachMatch(java.lang.String,java.util.regex.Pattern,groovy.lang.Closure)
"".eachMatch(~/test/) { it.toLowerCase() }

Comment by Bob Tiernay [ 09/Aug/11 ]

Can we change the title of this issue to "Type inference support for DGM methods" to more accurately reflect the totality of the issue? Thanks

Comment by Andrew Eisenberg [ 09/Aug/11 ]

Some more work to do.

Comment by Andrew Eisenberg [ 29/Sep/11 ]

Fixed everything that I will for this issue. Some of the lines above do not seem to be valid groovy code and some entries were incorrect.

I will add tests for each of this.





[GRECLIPSE-1142] groovy-eclipse-compiler depends on unavailable version of groovy-eclipse-batch Created: 24/Jul/11  Updated: 09/Aug/11  Resolved: 09/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Dominik Leszyk Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.10; Eclipse 3.7; m2e 1.0.0.20110607


Number of attachments : 0

 Description   

Currently groovy-eclipse-compiler plugin depends on groovy-eclipse-batch [1.7.10-SNAPSHOT],[1.8.0-SNAPSHOT] (AFAIK that means on version 1.7.10-SNAPSHOT or 1.8.0-SNAPSHOT). However this artifact is available in maven central repository in the following versions: 1.7.10-01, 1.7.10-02, 1.8.0-01, 1.8.0-02, 1.8.0-03.
Workaround is to use exclude section in project's POM.



 Comments   
Comment by Andrew Eisenberg [ 09/Aug/11 ]

This is now fixed with the latest release.





[GRECLIPSE-1140] Eclipse crashes and fails to start after launching script with multiple assignment Created: 23/Jul/11  Updated: 23/Jul/11  Resolved: 23/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Critical
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Attachments: Text File eclipse-workspace-log.txt    
Number of attachments : 1

 Description   

After executing the following script:

def (x, y) = [1,2]

eclipse crashes and fails to load. I had to remove the script file in order to restart.

See attached log for exception details



 Comments   
Comment by Andrew Eisenberg [ 23/Jul/11 ]

Not good. I wasn't aware that the syntax was even legal.

Comment by Andrew Eisenberg [ 23/Jul/11 ]

Easy fix. Now, multi-variable declarations will be displayed as a concatenation of all of the variable names (with commas).

Committed the fix.

Comment by Andrew Eisenberg [ 23/Jul/11 ]

Unfortunately, the source locations of TupleExpressions are incorrect (Groovy compiler issue), so clicking on the declaration will highlight the opening paren only.





[GRECLIPSE-1139] Content assist for closure arguments Created: 23/Jul/11  Updated: 05/Aug/11  Resolved: 25/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GRECLIPSE-1150 Include method-like content assist pr... Open
is related to GRECLIPSE-1170 If a field has an initializer with a ... Resolved
Number of attachments : 0

 Description   

It would be nice to be able to get content assist for the closure's arguments at the invocation point f(1,2) in the following example:

def f = { int x, int y -> }

f(1,2) // Content assist arguments


 Comments   
Comment by Andrew Eisenberg [ 23/Jul/11 ]

It is a different thing if the target closure of the content assist is a field or a local variable.

Comment by Andrew Eisenberg [ 25/Jul/11 ]

I have a solution that works for field proposals, but not for local variable proposals. I am going to write up some tests, close this issue and open a new one for local variable proposals.

That one will be harder since at the point of proposing, we don't have inferred type information for local variables.

Comment by Bob Tiernay [ 25/Jul/11 ]

Awesome! Great work Andrew

Comment by Andrew Eisenberg [ 25/Jul/11 ]

This issue is specifically about local variables and closures.

Comment by Bob Tiernay [ 05/Aug/11 ]

In the following example:

new C().c(i)

class C {
   def c = { int i ->
      println i
   } 
}

The type of c is not inferred, but it has content assist for the argument i. It would be nice if type inferencing could detect the fact that it is a Closure since content assist seems to already know this.

Comment by Bob Tiernay [ 05/Aug/11 ]

In the following example:

new C().c(i)

class C {
   def c = { int i ->
      println i
   } 
}

The type of c is not inferred, but it has content assist for the argument i. It would be nice if type inferencing could detect the fact that it is a Closure since content assist seems to already know this.

Comment by Andrew Eisenberg [ 05/Aug/11 ]

Created GRECLIPSE-1170 because this is a more general issue and might be solvable in a different way.





[GRECLIPSE-1138] Invalid semantic highlighting on consecutive overloaded static methods Created: 23/Jul/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File groovy-eclipse-semantic-highlight-bug.png    
Number of attachments : 1

 Description   

In the attached screenshot, the method invocation is not italicized and one of the overloaded methods is. This seems backwards.



 Comments   
Comment by Andrew Eisenberg [ 23/Jul/11 ]

Interesting...

Comment by Andrew Eisenberg [ 25/Jul/11 ]

Fixed with regression tests.





[GRECLIPSE-1137] Groovy formatter does not use correct Java formatter settings Created: 23/Jul/11  Updated: 17/Aug/11  Resolved: 17/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Formatting
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: D Gardner Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, SpringSource Tool Suite 2.7.1.RELEASE


Number of attachments : 0

 Description   

The formatter for Groovy source code does not use the correct Java formatter settings for indentation. In the STS (Eclipse) "Java -> Code Style -> Formatter" preferences, I edit the format and in the "Profile" dialog. On the "Indentation" tab, I set "Tab policy" to "Spaces only", "Indentation size" to "2", and "Tab size" to "8". Now, when I select some Groovy code and press "Ctrl+Shift+F", the Groovy editor uses the "Tab size" value of 8 spaces to indent my code, not the indentation size of "2" spaces. The editor/formatter should use the indentation size, not the tab size for indentation. The tab size is just the number of spaces to use to represent a tab character (I set mine to match my printer's and terminal's default tab size); it should have no effect on the code formatting.



 Comments   
Comment by Andrew Eisenberg [ 17/Aug/11 ]

A more complete specification of the behavior is this:

  • When set to "spaces only", tab size is used only for the tab key. Indentation size is how many spaces each line is indented by (this is what you describe above).
  • When set to "tabs only", indentation size is greyed out and its value is copied to tab size.
  • When set to "mixed", it looks like a reformat will use spaces and the indentation size.
Comment by Andrew Eisenberg [ 17/Aug/11 ]

It looks like the problem only occurs in "spaces" mode. The JDT preferences are confusing. It looks like when in "spaces" mode, we need to set the indentation size to be the tab size. If I do this, then everything is working for me. I will write up a few regression tests.

Unfortunately, the greclipse svn repo is closed for commits right now. When it is available again, I will commit the changes.

Comment by Andrew Eisenberg [ 17/Aug/11 ]

OK. Wrote up a few tests. Ultimately, I am confused by this since it seems like JDT is using the wrong value for spaces mode. Somehow JDT sets the tab size to be the indent size and then uses the tab size to calculate the number of spaces to use.

This is not a bug in JDT, but it may be some sort of legacy from a long time ago when the editor did not really distinguish between tab size and indent size.

Fixed now. Groovy code now exhibits the same behavior as Java code. Waiting to commit.

Comment by Andrew Eisenberg [ 17/Aug/11 ]

Will be available in next dev build (whenever that is).





[GRECLIPSE-1136] No type inferencing for multiple assignment Created: 22/Jul/11  Updated: 22/Jul/11  Resolved: 22/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GRECLIPSE-678 Type inferencing not supported for mu... Resolved
Number of attachments : 0

 Description   

There are no suggested members for x or y after the assignment

def (x, y) = [1, 2]
x // no content assist for Integer members


 Comments   
Comment by Andrew Eisenberg [ 22/Jul/11 ]

Duplicate of GRECLIPSE-678.

I was wondering how long it would take before someone complained about this. I was waiting for a complaint before I would work on it.





[GRECLIPSE-1135] In correct Open Declaration target on overloaded methods with typed arguments Created: 22/Jul/11  Updated: 05/Jun/14  Resolved: 05/Jun/14

Status: Closed
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.2.Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Unassigned
Resolution: Duplicate  
Labels: wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Ctrl+Click ing on f(1,2) will incorrectly navigate to f(List a, List b)

f(1,2)

static f(List a, List b) {}
static f(int a, int b) {}


 Comments   
Comment by Andrew Eisenberg [ 22/Jul/11 ]

We don't perform type inferencing of arguments to method calls, all we do is look at numbers of arguments. So this will navigate to the expected declaration:

f(1,2)

static f(List a) {}
static f(int a, int b) {}

Since groovy does dynamic dispatch, this is a very, very difficult task to perform correctly. See GRECLIPSE-729 for more information.

Comment by Bob Tiernay [ 22/Jul/11 ]

But shouldn't the editor at least try to find the closest match if static types exist and default to the first method if it cannot find a match? I would also assume that there are cases where type inferencing could be inaccurate but that doesn't mean there isn't value in trying.

Comment by Andrew Eisenberg [ 22/Jul/11 ]

We definitely could do better in this area.

Comment by Vasiliy Kizhaev [ 05/Jun/14 ]

This is issue seems to be similar to GRECLIPSE-1702





[GRECLIPSE-1134] groovy-eclipse-compiler can't compile Java 1.7 code Created: 22/Jul/11  Updated: 04/Oct/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Stefan Saring Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java: groovy-eclipse-compiler 2.5.1, Groovy 1.8.0, JDK 1.7.0 RC, Maven 3.0.3 (NetBeans 7.0 RC1)
OS: Ubuntu 10.04


Number of attachments : 0

 Description   

My project uses Maven and the groovy-eclipse-compiler for mixed Java/Groovy compilation. Everything works fine when compiling the Java sources in Java 1.6 mode.
When I add Java 7 features and switching the compiler to Java 1.7 mode, then the code does not compile. The compiler seems still to work in Java 1.6 mode.

Here's the error message when running "maven clean compile":

[compiler:compile]
Using Groovy-Eclipse compiler to compile both Java and Groovy files
Compiling 56 source files to /home/eddie/Private/working/java/JavaSE-Projects/sportstracker/sportstracker/target/classes
----------
1. ERROR in /home/eddie/Private/working/java/JavaSE-Projects/sportstracker/sportstracker/src/main/java/de/saring/sportstracker/gui/STMain.java (at line 60)
ArrayList<String> aList = new ArrayList<>();
^
Syntax error on token "<", ? expected after this token

Here's the part of the pom.xml with the groovy-eclipse-compiler configuration.

...
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<verbose>false</verbose>
<source>1.7</source>
<target>1.7</target>
<encoding>$

{project.build.sourceEncoding}

</encoding>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<!-- 2.5.1 final can't be used, it requires an Groovy snapshot release (bug) -->
<version>2.5.1-M3</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>1.8.0-03</version>
</dependency>
</dependencies>
</plugin>
...

When I remove the line
<compilerId>groovy-eclipse-compiler</compilerId>
everything works fine, it compiles without problems. So it seems that the groovy-eclipse-compiler can't handle the new Java 1.7 mode.

It would be great when this could be fixed soon...



 Comments   
Comment by Andrew Eisenberg [ 22/Jul/11 ]

That's correct. Currently, JDT support for Java 1.7 is in pre-beta. So, we do not ship Groovy-Eclipse with Java 1.7 support yet. The earliest that we will get this working is when Eclipse 3.7.1 is released in September, but that is dependent on how JDT for 1.7 is progressing.

Comment by Stefan Saring [ 22/Jul/11 ]

OK, so we need to wait...
Anyway, thanks for the incredible fast comment!

Comment by Andrew Eisenberg [ 28/Sep/11 ]

This is now available. Use the 2.5.2-SNAPSHOT version of groovy-eclipse-compiler and use the 1.8.2-3 version of groovy-eclipse-batch.

Comment by Stefan Saring [ 04/Oct/11 ]

Works perfectly now (groovy-eclipse-compiler 2.5.2-01 in Eclipse 3.7.1).

Comment by Andrew Eisenberg [ 04/Oct/11 ]

Thanks for getting back to me.





[GRECLIPSE-1133] Test methods which have spaces in their names cannot be navigated to from JUnit results pane Created: 22/Jul/11  Updated: 22/Jul/11  Resolved: 22/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Edd grant Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.10 AMD 64, SpringSource STS 2.7.1


Issue Links:
Duplicate
duplicates GRECLIPSE-652 Problems with test methods that have ... Open
Number of attachments : 0

 Description   

Test method which have spaces in their names cannot be navigated to from JUnit results pane, although pretty trivial it's a bit of a pain, particularly when dealing with test classes which have loads of tests, since the test has to be located manually.

When I click on the test name in the JUnit view I get the following error: Method '<test name up to the first space>' not found. Opening the test class.

Here's an example Spock test case:

def 'this test will execute just fine but cannot be accessed through the junit view'() 
  when:
    //Do something arbitrary here.
    def someVariable
  then:
    //Deliberately fail to prompt me to click on the test name in the
    //JUnit results view so I can see what went wrong.
    org.junit.Assert.assertFalse(true)
}}


 Comments   
Comment by Andrew Eisenberg [ 22/Jul/11 ]

Duplicate of GRECLIPSE-652

Comment by Edd grant [ 22/Jul/11 ]

Just seen this has been marked as a dupe, apologies - I did search for existing bugs but simply missed that one.





[GRECLIPSE-1132] Eclipse builds broken after GRECLIPSE upgrade Created: 22/Jul/11  Updated: 26/Oct/11  Resolved: 26/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Critical
Reporter: Marco Trevisan Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File bookmarks.xml    
Number of attachments : 1

 Description   

After upgrading GRECLIPSE to the last nightly (2.5.2.xx-20110721-1500-e37), one of my groovy-enabld Java projects failed building.
The error log entry is as follows:

Error
Fri Jul 22 07:07:09 CEST 2011
Errors running builder 'Java Builder' on project 'MyProject'.

java.lang.NullPointerException
	at org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1039)
	at org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1018)
	at org.codehaus.groovy.classgen.AsmClassGenerator.doConvertAndCast(AsmClassGenerator.java:3843)
	at org.codehaus.groovy.classgen.AsmClassGenerator.doConvertAndCast(AsmClassGenerator.java:3838)
	at org.codehaus.groovy.classgen.AsmClassGenerator.storeThisInstanceField(AsmClassGenerator.java:2843)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitFieldExpression(AsmClassGenerator.java:2769)
	at org.codehaus.groovy.ast.expr.FieldExpression.visit(FieldExpression.java:38)
	at org.codehaus.groovy.classgen.AsmClassGenerator.evaluateEqual(AsmClassGenerator.java:4050)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:1488)
	at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitAndAutoboxBoolean(AsmClassGenerator.java:4127)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:1469)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:735)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:623)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:598)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructor(ClassCodeVisitorSupport.java:120)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructor(AsmClassGenerator.java:685)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1153)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:274)
	at org.codehaus.groovy.control.CompilationUnit$6.call(CompilationUnit.java:861)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1147)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:585)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:563)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:540)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1501)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:831)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:680)

Regards,
Marco



 Comments   
Comment by Andrew Eisenberg [ 22/Jul/11 ]

Have you isolated this down to a single project? If so, is this something that you can share?

I'm looking into what has changed in this area since the 2.5.2 release. That could help point to the problem.

Comment by Marco Trevisan [ 22/Jul/11 ]

In one project I had an "internal compiler error" referring to the NPE at ClassNode.java:1039 on a groovy class implementing an interface, so at first I thought it was something related to the interface.

But then I emptied the class, removing the body, the extends + implements declaration and all the imports, and the problem was still there.
For this reason it doesn't seem to me a problem related to that particular class and its internal syntax.

In another workspace I had other "internal compiler error" cases, all related to the same NPE, in groovy classes (which are not related one another).

The common thing here is that there was exactly one groovy class triggering the "internal compiler error" for each project.

If you still need the source of one of them, I'll try to do what I can (I guess you need the exact same code, comments included)

Comment by Andrew Eisenberg [ 22/Jul/11 ]

Yes, source code would be great.

Is it always reproducible? Does it happen immediately after startup, or is it after a build or two? If you close that project causing the error, does the workspace behave as expected? If you remove that single file from the build path, do you still have the problem? What if you remove the file from the build path, and then restart?

If the core types are somehow being damaged, then you will need a restart before things will start behaving as normal again.

Feel free to send me sample code to my private email if there is anything proprietary in it.

Comment by Andrew Eisenberg [ 22/Jul/11 ]

Another thing I can try is undoing the part of the fix for STS-1106 that will log errors to the error log if a core type is damaged. It could be that somehow this fix is damaging core types itself (I don't know how this could be since I was very careful to avoid anything potential harmful, but there could be something going on). We'll explore this route if I can't find the root of the problem otherwise.

Comment by Marco Trevisan [ 23/Jul/11 ]

Hi Andrew,

The issue is always reproducible, it happens immediately on startup, it does not (seem to) depend on how many times I clean the project or on the sequence I use to build/restart eclipse. The broken project does not have a negative impact on the other projects in the workspace, so I can also keep it open. It does have (obviously) negative impact on dependent projects, which do not build because Eclipse tells you to fix that project before.

If I remove form the build path the groovy class causing the NPE, the build restarts and the NPE shows up in another groovy class of the project.

The next groovy class causing the compiler error is another class that extends HibernateDaoSupport and implements a custom DAO interface, as the first one does.
Both have annotations @Transactional and @Secured("ROLE_USER") in their method implementations, and the method implementations are really simple (no closures, no anonymous inner classes, two-liners of groovy code).

In the other workspace, though, groovy classes do not extend HibernateDaoSupport. They are all quite simple and plain.

I had to revert my Eclipse install directory using Time Machine because my productivity is compromised (I have some ANT scripts which work on Eclipse projects and expect the "build" directory to be up to date with sources).

Regards,
Marco

Comment by Marco Trevisan [ 23/Jul/11 ]

Attached "bookmarks.xml": the working Eclipse config before I install the GRECLISPE update.

Groovy version: 1.7.10 (I didn't switch compiler level to 1.8 because I also work with Grails-1.3.7 projects).

Comment by Andy Clement [ 25/Jul/11 ]

I have sample code that creates this issue, I'll take a look at it today, it doesn't relate to the 'unable to resolve E' thing, it relates to the inconsistent class file problem.

Comment by Marco Trevisan [ 25/Jul/11 ]

Hi Andy,

I just upgraded GRECLIPSE to 2.5.2.xx-20110725-0900-e37 and the exception has stopped rising.
As far as I'm concerned we can close the ticket as fixed.

Thank you all guys, you've been great! :-D

Just for the records: the only kind of error I still see in the Eclipse error log is as follows (but I'm not aware of any negative impact in the IDE usage):

null
Error
Mon Jul 25 23:55:46 CEST 2011
Groovy bug when compiling.

BUG! exception in phase 'semantic analysis' in source unit '/.../FormSubmitController.groovy' Pb(538) Inconsistent classfile encountered: The undefined type parameter T is referenced from within SubmitController.2
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:965)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:587)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:536)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1937)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1207)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:707)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1175)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:801)
	at com.google.gdt.eclipse.designer.util.Utils.parseUnit(Utils.java:1152)
	at com.google.gdt.eclipse.designer.builders.participant.AbstractCompilationParticipant.processAnnotationsEx(AbstractCompilationParticipant.java:68)
	at com.google.gdt.eclipse.designer.builders.participant.AbstractCompilationParticipant.access$0(AbstractCompilationParticipant.java:60)
	at com.google.gdt.eclipse.designer.builders.participant.AbstractCompilationParticipant$1.run(AbstractCompilationParticipant.java:51)
	at org.eclipse.wb.internal.core.utils.execution.ExecutionUtils.runLog(ExecutionUtils.java:100)
	at com.google.gdt.eclipse.designer.builders.participant.AbstractCompilationParticipant.processAnnotations(AbstractCompilationParticipant.java:49)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:683)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:391)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:61)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:184)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.eclipse.jdt.internal.compiler.problem.AbortCompilationUnit: Pb(538) Inconsistent classfile encountered: The undefined type parameter T is referenced from within SubmitController.2
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.abort(CompilationUnitDeclaration.java:99)
	at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:158)
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1992)
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:2055)
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.undefinedTypeVariableSignature(ProblemReporter.java:6806)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1240)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1308)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1095)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1257)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createFields(BinaryTypeBinding.java:411)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:368)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:694)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:673)
	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:308)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:114)
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:126)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.memberTypes(BinaryTypeBinding.java:1078)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.mightHaveInners(JDTClassNode.java:105)
	at org.codehaus.groovy.control.ResolveVisitor.resolveNestedClass(ResolveVisitor.java:328)
	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:304)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:292)
	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:261)
	at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:241)
	at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:253)
	at org.codehaus.groovy.control.ResolveVisitor.visitField(ResolveVisitor.java:197)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1149)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
	at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1381)
	at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:165)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:626)
	at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:693)
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:956)
	... 31 more

Regards,
Marco

Comment by Andy Clement [ 25/Jul/11 ]

That build include a reverted change to address the NPE, but the reverted change made the inconsistent class file problem re-appear (I knew it would, but the inconsitent classfile issue was slightly less painful). I've since fixed it all properly, the next build later today will address the NPE and the inconsistent classfile.

Comment by Marco Trevisan [ 26/Jul/11 ]

Hi Andy,

I just installed the 20110725-1800 build and I can confirm the latter exception stopped rising too

Regards,
Marco

Comment by Andy Clement [ 26/Jul/11 ]

Two fixes here:

  • the inconsistent class file issue is the groovy bug http://jira.codehaus.org/browse/GROOVY-4934 - but the patch I supplied them to address it in 1.8/1.9 needed a tweak for 1.7
  • the NPE is because groovy doesnt set the interfaces in getPlainNodeReference, appears to be another groovy bug.

Anyway, all sorted now.

Comment by Mauro Molinari [ 25/Oct/11 ]

I'm seeing the "Inconsistent class file" issue with Greclipse 2.5.2.xx-20110929-1800-e37. Is it expected?

Comment by Andrew Eisenberg [ 25/Oct/11 ]

No. This is something you should not be seeing. Can you be a bit more specific as to when you are getting it? Is it on full builds? Incremental builds? While editing? Do you know which files produce it?

Comment by Mauro Molinari [ 25/Oct/11 ]

Yes, I have one file with two such errors, reported on line 1.
The strange thing is that I see no relation between that file and the class the error report talks about.
I mean, I have a Java class DynamicFormConfigurationBean with the following errors reported at line 1:

Inconsistent classfile encountered: The undefined type parameter T is referenced from within SubmitController.1
Inconsistent classfile encountered: The undefined type parameter T is referenced from within SubmitController.2

But DynamicFormConfigurationBean has no reference to SubmitController.

SubmitController is a Groovy compiled class within a JAR file in the DynamicFormConfigurationBean project classpath.

If I right click on the Java editor for DynamicFormConfigurationBean and click on "Validate", the validation completes with no errors or warnings, but the red marks are still there.

Comment by Andy Clement [ 25/Oct/11 ]

If you are consuming classfiles that are inconsistent from a jar, upgrading groovy-eclipse won't fix that. The library with them in needs rebuilding. As Andrew says, determining the class (and where it comes from) will help a lot.

Comment by Mauro Molinari [ 25/Oct/11 ]

So you mean the SubmitController compiled class might have been compiled in a "wrong" way by an old Groovy/Greclipse version, thus causing this error message?

Comment by Andy Clement [ 25/Oct/11 ]

Yes, there was a known problem with inner classes (like your .1 and .2 types). You need to have them recompiled with a version of Groovy-Eclipse that does not include the groovy bug.

Comment by Mauro Molinari [ 26/Oct/11 ]

This is now clear, thank you Andy!

Comment by Mauro Molinari [ 26/Oct/11 ]

Sorry Andy, I actually need some more clarification.

From what I understand from this bug and GROOVY-4934, the problem has actually been solved in Greclipse but not in the Groovy compiler. So, if I make that JAR using Gradle, even if this uses the latest version of the Groovy compiler I will still get a JAR with a corrupted class file in it, won't I?

Secondly, apart from the fact that I get that error in Eclipse, are there any consequences at runtime? I fear that when the code of that corrupted class is executed, some runtime exception will be thrown, won't it?





[GRECLIPSE-1131] Type inferencing should work inside of DGM methods called with non-collection arguments Created: 21/Jul/11  Updated: 22/Jul/11  Resolved: 22/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.2.Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following will infer the type from the list:

[1].each {
    it
}

however, the following will not:

1.each {
    it
}


 Comments   
Comment by Andrew Eisenberg [ 21/Jul/11 ]

I didn't even know that was a valid expression. I'll have a look at the meaning of each to see how it really works and then I can make some changes to how the inferencing engine interprets it.

Comment by Andrew Eisenberg [ 22/Jul/11 ]

I see that in org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.asCollection(Object), the last line is this:

        else {
            // let's assume it's a collection of 1
            return Collections.singletonList(value);
        }

So, it appears this is a nice heuristic for the inferencing engine, that if a target of an iteration block is not itself iterable, then just return the type of self.

Comment by Andrew Eisenberg [ 22/Jul/11 ]

Fixed with regression tests.





[GRECLIPSE-1129] Type parameters on methods are not respected Created: 20/Jul/11  Updated: 29/Jul/14  Resolved: 29/Jul/14

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Andrew Thorburn Assignee: Denis Murashev
Resolution: Fixed  
Labels: Generics, triaged, type-inference, wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File GroovyGenericsFailureScreenshot.png    
Issue Links:
Duplicate
is duplicated by GRECLIPSE-1169 MapWithDefault.newInstance should inf... Resolved
Related
is related to GRECLIPSE-1696 Return generic type of a generic meth... Resolved
Number of attachments : 1

 Description   

When using the following code snippet, the type of the variable col is not correctly inferred:

class A { }

class B extends A {}

static <T extends A> T loadSomething(T t) {
	return t
}

def col = loadSomething(new B())

I would expect that the variable type is inferred as B, but what I see when I mouse over it is that it is inferred as A<A> - not quite right. See the attached screen shot.

What this means is that if I were to add a method to B, that method would be underlined, as the inferencing engine is unable to find it on A. However, if I add a method on A, GRECLIPSE finds it as expected, and it is not underlined.

I know this issue is similar to both GRECLIPSE-999 and GRECLIPSE-997, but is is also slightly different as it uses the T extends SuperClass syntax (might also apply to ? extends SuperClass syntax. Given the comments in 997, I'm not expecting this to be particularly easy to fix, but hey. Maybe it will be



 Comments   
Comment by Andrew Eisenberg [ 25/Jul/11 ]

The problem here has nothing to do with the extends clause in the type parameter, but rather that we are not supporting type inferencing of method type parameters.

Here is a variant of the script above that does correctly infer the type:

class A { }
class B extends A { }
class C<T extends A> {
	T loadSomething() {
		return null
	}
}
new C<B>().loadSomething()
Comment by Andrew Eisenberg [ 25/Jul/11 ]

Changing title to more closely reflect what the problem is.

Comment by Andrew Thorburn [ 25/Jul/11 ]

Ahh, right. Hadn't considered that particular possibility. Is this likely to be fixed at some point?





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1128] Changes to annotatedBy pointcut Created: 19/Jul/11  Updated: 27/Jul/11  Resolved: 27/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 27/Jul/11 ]

Committed with regression tests.





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1127] Support "isThisType" and deprecate "currentTypeIsEnclosingType Created: 19/Jul/11  Updated: 19/Jul/11  Resolved: 19/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 19/Jul/11 ]

Done





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1126] use "contribution" instead of "accept" for linking pointcuts to contribution blocks Created: 19/Jul/11  Updated: 19/Jul/11  Resolved: 19/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 19/Jul/11 ]

Done





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1125] Update meta-DSL script to provide editing support for new features. Created: 19/Jul/11  Updated: 28/Sep/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 28/Sep/11 ]

meta-DSLD is now updated.





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1124] Update documentation for new DSLD language features Created: 19/Jul/11  Updated: 28/Sep/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 28/Sep/11 ]

Documentation has now been updated.





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1123] assertVersion should behave like the old supportsVersion Created: 19/Jul/11  Updated: 19/Jul/11  Resolved: 19/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 19/Jul/11 ]

Now done.





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1122] supportsVersion should return boolean instead of throwing exception Created: 19/Jul/11  Updated: 19/Jul/11  Resolved: 19/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Andrew Eisenberg [ 19/Jul/11 ]

Now working.





[GRECLIPSE-1121] Generics problem causes inconsistent class file Created: 19/Jul/11  Updated: 16/Oct/11  Resolved: 16/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive minimal_generics_inconsistency.zip    
Number of attachments : 1

 Description   

Import the attached project and there should be an error in the class Inners. If the problem doesn't appear on the initial build, then do a whitespace change in Inners.

The problem has something to do with inner classes being both in a concrete and abstract type.



 Comments   
Comment by Andy Clement [ 19/Jul/11 ]

> The problem has something to do with inner classes being both in a concrete and abstract type.

No, this is due to what I mentioned yesterday, the groovy compiler is producing incorrect signature attributes. This only becomes visible when something happens that causes JDT to try to consume the class file for one of these. So on a full build you don't typically see it, but on an incremental build where the binary form of the groovy type is faulted in as a dependency, it appears.

The JVM doesn't usually care about these things (i.e. the code will run) but Eclipse deliberately checks the attributes are valid. You can recreate this problem without using groovy-eclipse by compiling the code with groovyc and then attempting to depend upon that compiled code from a pure java project in eclipse.

Raised as groovy bug GROOVY-4934.

That groovy bug also contains a distilled down testcase smaller than the one here that shows the problem.

Comment by Andy Clement [ 16/Oct/11 ]

All fixed up as far as I am aware. Groovy-Eclipse also fixes this problem in the 1.7 compiler level, which groovy currently does not.





[GRECLIPSE-1120] Proposed changes to DSLD syntax Created: 19/Jul/11  Updated: 28/Sep/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
? Remaining Estimate: Not Specified Remaining Estimate: Not Specified
? Time Spent: Not Specified Time Spent: Not Specified
? Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GRECLIPSE-1092 Content assist for method calls with ... Sub-task Resolved Andrew Eisenberg  
GRECLIPSE-1096 Allow access to parameters of enclosi... Sub-task Resolved Andrew Eisenberg  
GRECLIPSE-1122 supportsVersion should return boolean... Sub-task Resolved Andrew Eisenberg  
GRECLIPSE-1123 assertVersion should behave like the ... Sub-task Resolved Andrew Eisenberg  
GRECLIPSE-1124 Update documentation for new DSLD lan... Sub-task Resolved Andrew Eisenberg  
GRECLIPSE-1125 Update meta-DSL script to provide edi... Sub-task Resolved Andrew Eisenberg  
GRECLIPSE-1126 use "contribution" instead of "accept... Sub-task Resolved Andrew Eisenberg  
GRECLIPSE-1127 Support "isThisType" and deprecate "c... Sub-task Resolved Andrew Eisenberg  
GRECLIPSE-1128 Changes to annotatedBy pointcut Sub-task Resolved Andrew Eisenberg  
Number of attachments : 0

 Description   

In 2.5.2, we will be making some changes to the syntax of DSLDs. As much as possible, this will be backwards compatible, but some will not be. Here are some proposed changes that are not already covered under jiras.

  • Instead of using {{pointcut().accept { ... } }}, we will support {{contribution( pointcut() ) { ... }

    }}. The idea here is to bring the syntax more inline with IntelliJ's GDSL. Also, there will be no way to forget the pesky extra parens that you need around the pointcut declaration. The old syntax style will still be supported.

  • supportsVersion will no longer throw an exception to end processing of the script. Rather, it will return a boolean. This will allow you to selectively run different portions of the script under different circumstances. Eg-
    if (supportsVersion(groovy:"1.8.0")) {
        // do something specific for groovy 1.8
    } else if (supportsVersion(groovy:"1.7.0")) {
        // do something specific for groovy 1.7
    }
    
  • The old way of throwing a runtime exception to stop processing when a version requirement fails will still work with assertVersion
  • The pointcut currentTypeIsEnclosingType will be replaced by isThisType. Old pointcut will still be available, but deprecated
  • The pointcut annotatedBy will allow the accessing of its attributes. Eg-
    contribution(currentType(annotatedBy(name('groovy.transform.TupleConstructor') & 
      hasAttribute(name("includeSuperFields") & value(true)))) {
      // add a new constructor
    }
    
  • Ability to add constructors as DSL proposals.

Let me know what you think of these changes and if there is anything that you really want changed. There will probably be more changes. This is just an initial list.



 Comments   
Comment by Andrew Eisenberg [ 28/Sep/11 ]

Complete.





[GRECLIPSE-1118] Better editing support for groovy files that are not on the build path Created: 19/Jul/11  Updated: 28/Sep/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, we explicitly disable much of the editing support for Groovy files that are not on the build path. This means that editing scripts, gradle files, or anything else not on the build path will not be too easy. Since we are trying to provide better gradle support, we should be doing something about this.

It would be nice to enable standard editor features like navigation, outline view, content assist, type inferencing, and dsl support.

I don't remember exactly why we disabled this in the past, but I do know that there were many exceptions being added to the log when editing files not on the build path.



 Comments   
Comment by Andrew Eisenberg [ 19/Jul/11 ]

I have been playing around with this in my local workspace and this is working quite well. By simply removing the guards on GroovyCompilationUnit.buildStructure and elsewhere, I now have navigation, content assist, type inferencing, and mark occurrences working. The caveats are that files outside of the build path cannot be referenced by any other files, search doesn't work inside of these files, and refactoring does not work. These are restrictions that is similar to those for Java files in JDT.

Comment by Andrew Eisenberg [ 19/Jul/11 ]

I am considering committing what I have and seeing if other people have problems with editing.

The next step is to allow the ability to augment (or replace) the lookup path of script files.

Comment by Andy Clement [ 20/Jul/11 ]

So as we discussed, we can choose to not be eclipsey in terms of the extra lookups. Both the ability to use ast transforms that are part of the project and grab support use a classloader to make types available that are not on the classpath. The classpath to be used could be communicated in a similar way in which we currently communicate that the file is a script (see GCUD.tagAsScript() and how that filters through to GCUScope). I think this is worth continuing with once we have a real use case and the gradle support is able to conjure up the classpath to use. I'll check with Kris next week about whether the API can provide it. Where we will have to be careful is that using a classloader kind of just gives us augmentation of the classpath, we'll need to also affect the JDT resolver and prevent it finding things in these situations (if we truly want to use an entirely different classpath for the scripts).

Now the script support seems to be behaving, perhaps we also need to make the change that will mean the scripts are not passed to the compiler (for a proper build), even if in a source folder (if they match the script patterns). ie. remove our old hacky way of supporting scripts.

Comment by Andrew Eisenberg [ 28/Sep/11 ]

I am resolving this issue as fixed since the main part of this is done. Now, editing groovy files outside the build path is supported much more deeply. It is an entirely different problem to enhance the classpath for reconciling of these files.





[GRECLIPSE-1117] Problem occur while installing Groovy IDE in Ecllipse Created: 19/Jul/11  Updated: 19/Jul/11  Resolved: 19/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Elakkiya Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: 4 weeks, 1 day, 16 hours
Time Spent: Not Specified
Original Estimate: 4 weeks, 1 day, 16 hours
Environment:

Windows 7,Eclipse 3.7(Indigo)


Number of attachments : 0

 Description   

Am using Eclipse 3.7.0,Am trying to install Groovy and i used this Link
http://groovy.codehaus.org/Eclipse+Plugin

While installing this /link i got error Like this.How Can i Rectify this problem

Error Message:
not complete the install because one or more required items could not be found.
Software being installed: Groovy-Eclipse Feature 2.0.0.xx-20091027-1400-e34 (org.codehaus.groovy.eclipse.feature.feature.group 2.0.0.xx-20091027-1400-e34)
eclipse ide groovy



 Comments   
Comment by Andrew Eisenberg [ 19/Jul/11 ]

It looks like you are using the wrong update site for your version of Eclipse. Try:
http://dist.springsource.org/release/GRECLIPSE/e3.7/

Comment by Andrew Eisenberg [ 19/Jul/11 ]

I'm guessing that this will solve your problem, but please re-open if you continue to have problems installing.





[GRECLIPSE-1116] Stack Overflow while reorganizing Groovy classes Created: 18/Jul/11  Updated: 26/Jul/11  Resolved: 26/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: David Tonhofer Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora 14
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Eclipse 3.6.1
Using Groovy 1.8


Issue Links:
Related
relates to GRECLIPSE-531 [compiler] Broken code causes infinit... Resolved
Number of attachments : 0

 Description   

Refactoring:

Class A exists
Create class B
Try to modify A by adding "extends B" --> Stack Overflow (also, on restart Eclipse complains about stack overflow)

The Eclipse log follows (there are lots of other errors before but they are separated from this one by a few minutes, so assuming unrelated).

!ENTRY org.eclipse.ui 4 0 2011-07-18 22:42:21.352
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.StackOverflowError
at java.lang.Character.toLowerCase(Character.java:4208)
at java.lang.Character.toLowerCase(Character.java:4175)
at java.beans.Introspector.decapitalize(Introspector.java:263)
at org.codehaus.groovy.classgen.VariableScopeVisitor.getPropertyName(VariableScopeVisitor.java:194)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:156)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
......
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)

!ENTRY org.eclipse.ui 4 4 2011-07-18 22:42:24.889
!MESSAGE Save All Failed

!ENTRY org.eclipse.ui 2 0 2011-07-18 22:42:24.890
!MESSAGE Save All Failed
!STACK 0
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:762)
at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:981)
at org.codehaus.groovy.ast.ClassNode.isScript(ClassNode.java:1202)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:147)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
....
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)

!ENTRY org.eclipse.core.jobs 4 2 2011-07-18 22:42:28.635
!MESSAGE An internal error occurred during: "Building workspace".
!STACK 0
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1056)
at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:1050)
at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:990)
at org.codehaus.groovy.ast.ClassNode.isScript(ClassNode.java:1202)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:147)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
....
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)

!ENTRY org.eclipse.ui 4 4 2011-07-18 22:42:29.360
!MESSAGE An internal error has occurred.
!STACK 0
org.eclipse.swt.SWTException: Widget is disposed
at org.eclipse.swt.SWT.error(SWT.java:4083)
at org.eclipse.swt.SWT.error(SWT.java:3998)
at org.eclipse.swt.SWT.error(SWT.java:3969)
at org.eclipse.swt.widgets.Widget.error(Widget.java:466)
at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:403)
...

!ENTRY org.eclipse.ui 4 0 2011-07-18 22:43:16.984
!MESSAGE Unable to create editor ID org.codehaus.groovy.eclipse.editor.GroovyEditor: Editor could not be initialized.
!STACK 0
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1056)
at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:1050)
at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:990)
at org.codehaus.groovy.ast.ClassNode.isScript(ClassNode.java:1202)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:147)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
....
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:179)
at org.codehaus.groovy.classgen.VariableScopeVisitor.findClassMember(VariableScopeVisitor.java:177)

!ENTRY org.eclipse.ui 4 0 2011-07-18 22:43:16.991
!MESSAGE Error occurred during status handling
!STACK 0
java.lang.NullPointerException
at org.eclipse.ui.internal.statushandlers.InternalDialog$7.widgetSelected(InternalDialog.java:970)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282)
at org.eclipse.swt.widgets.Widget.sendSelectionEvent(Widget.java:1396)
at org.eclipse.swt.widgets.Link.gtk_button_release_event(Link.java:340)



 Comments   
Comment by David Tonhofer [ 18/Jul/11 ]

Addition:

The problem may stem from this structure:

Base Class:

class DsMaps {
   ....
}

Derived class with inner Class:

class DsMapForSmartAttr extends DsMaps {

    public static class DsMaps {
    }

    public static DsMaps getX() {
       ....
    }
}
Comment by Andrew Eisenberg [ 25/Jul/11 ]

I have been trying to recreate the problem with some variant of the code that you have here. However, I cannot.

This stack trace is usually an indication of GRECLIPSE-531. Do you remember the steps that you took to get problem? This would help me reproduce.

Comment by David Tonhofer [ 26/Jul/11 ]

Hi Andrew.

I'm sorry to say I cannot reproduce it. Everything works fine so far for things like

class A {

}

class B extends A {

    public static class A {
        // This is the class referenced by the the *extends*
        // Does that make sense?
    }

    public static A getA() {
        return new A()
    }
    
}

I recall that the error came up while I was really messily redesigning the class hierarchy. But that's about it.

Comment by Andrew Eisenberg [ 26/Jul/11 ]

Thanks for getting back to me. I will close this issue. But, please reopen and attach the entire stack trace if you ever see this happen again.





[GRECLIPSE-1115] groovy.transform.Field annotation produces a script error in the editor Created: 17/Jul/11  Updated: 18/Jul/11  Resolved: 18/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following code will run:

import groovy.transform.Field

@Field int test = 1

println test

but produces an error in the editor:

Multiple markers at this line

  • Groovy:Error: annotation @Field can only be used within a Script body.
  • implements groovy.lang.Script.run


 Comments   
Comment by Andrew Eisenberg [ 18/Jul/11 ]

Sending this over to Andy to look at, who is more familiar with this part of the code.

Comment by Andy Clement [ 18/Jul/11 ]

problem was that we are setting the column number of the run() method that is created at runtime to contain the code generated for the script. Having the column set trips up the code in groovy that recognizes the run method - and this was being called by the Field transform. I've adjusted the check to consider the method name and signature, rather than the source location. Fixes this.





[GRECLIPSE-1114] Code completion not working inside inline closure invocation Created: 17/Jul/11  Updated: 07/Oct/11  Resolved: 07/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7


Number of attachments : 0

 Description   

The following will not suggest foo:

(1..10).each { 
    // foo() not suggested
}

def foo() {
    
}

however, this will:

def bar = { 
    // foo() suggested
}

def foo() {
    
}


 Comments   
Comment by Andrew Eisenberg [ 18/Jul/11 ]

The problem here is a confusion with the type of this. Inside the each closure, this is inferred to be of type Integer, but inside the field initializer closure, this is inferred to be the type of the script.

Although that is technically correct, the delegate methods in the each closure (which come from the script) should be available too in content assist.

Comment by Andrew Eisenberg [ 07/Oct/11 ]

Fixed and committed with regression tests.





[GRECLIPSE-1113] Copy and paste of groovy file with comment before package declaration causes syntax error Created: 16/Jul/11  Updated: 18/Oct/11  Resolved: 18/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Refactoring, User Interface
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Copy and paste of groovy file with comment before package declaration causes syntax error:

If this is the copied script Test.groovy:

/**
 * Package comment
 */
package com.test

This is the result after copying:

CopyOfTest**
 * Package comment
 */
package com.test


 Comments   
Comment by Andrew Eisenberg [ 18/Jul/11 ]

A little more clarification please. What are you copy/pasting? When I try copy/paste of the file (from the package explorer) to another package, I do not see the problem.

Comment by Bob Tiernay [ 18/Jul/11 ]

Yes. Create Test.groovy in non default package. Select file in package editor. Copy file (ctrl+c). Paste file into same package. File should be called CopyOfTest.groovy. The invalid comment should look like:

CopyOfTest**
 * Package comment
 */
Comment by Andrew Eisenberg [ 18/Jul/11 ]

Thanks. I can reproduce now. This problem only occurs when pasting into the same package as the original and only when the copied source file is a script with no class declarations. Ie-

This works:

/**
 * comment
 */
package com.test2

class Other { }

But this does not:

/**
 * comment
 */
package com.test2

def x
print x
Comment by Andrew Eisenberg [ 18/Oct/11 ]

Fixed.

The problem was that we were erroneously returning the script's name declaration as a reference to the type. The script name declaration doesn't really exist, but we have to put something there, so we mark the script as having a name declaration at location 0 with length 0.

The refactoring engine was picking this up as a match and erroneously replacing the (non-existent) name with the new name.





[GRECLIPSE-1111] Syntax highlighting fails for multiline $/.../$ strings Created: 16/Jul/11  Updated: 26/Jul/11  Resolved: 26/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Bob Tiernay Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7


Attachments: File groovy-eclipse-syntax-bug.groovy     PNG File groovy-eclipse-syntax-bug.png    
Testcase included: yes
Number of attachments : 2

 Description   

Syntax highlighting fails for consecutive static definitions



 Comments   
Comment by Andrew Eisenberg [ 18/Jul/11 ]

The problem here is because of the trailing $/. This is confusing the highlighter because it conflicts with Groovy 1.8's new $/.../$ multiline string.

Comment by Andrew Eisenberg [ 18/Jul/11 ]

I can somewhat fix the problem. Currently, the opening $/ matches eagerly. That is, if there is no matching closing \$, the entire remainder of the file will match.

I can make a small change to the highlighting lexer such that it will no longer match eagerly and a closing \$ will be required for the match. Unfortunately, the example you provide will still fail to highlight properly since there is also a closing \$ in a string literal later on. But this is an improvement.

After this change, the simplest way to reproduce is to create a file like this:

~/^$/
def invalidHighlighting = "/$"

Everything between the $/.../$ will be highlighted incorrectly. But remove the closing \$ and the problem goes away.

Comment by Andrew Eisenberg [ 18/Jul/11 ]

Update title to better reflect the problem.

Will commit the change later today.

Comment by Andrew Eisenberg [ 26/Jul/11 ]

Fixed as well as it can be.





[GRECLIPSE-1110] Problem with generic return types of methods defined in binary classes Created: 13/Jul/11  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The attachment on GRECLIPSE-1105 is available here:
https://jira.codehaus.org/secure/attachment/55971/TestGroovyEclipse.zip

To reproduce:

  1. Install test project
  2. Create new groovy class with the text shown below.
  3. initially when is underlined
  4. Now, comment out the active import statement and uncomment the other one
  5. underline goes away.

Here is the text of the class:

//import samestructure.ChoiceDefinition
import org.apache.camel.model.ChoiceDefinition
new ChoiceDefinition().to("").when()

Note that org.apache.camel.model.ChoiceDefinition comes from binary and samestructure.ChoiceDefinition is source. When I copy both org.apache.camel.model.ChoiceDefinition and org.apache.camel.model.ProcessorDefinition to source, then the underline goes away.

Digging into this, it looks like the return type of the binary to is ProcessorType<Type> and the return type of the source to is Object<Type>. The latter is something that the inferencing engine knows how to handle, but the former is not.



 Comments   
Comment by Andy Clement [ 13/Jul/11 ]

> The latter is something that the inferencing engine knows how to handle, but the former is not.

Just want to check that statement is the right way round? It says that the inferencing engine can handle Object<Type> but not ProcessorType<Type>? What does 'Object<Type>' mean as Object is not generic?

Comment by Andrew Eisenberg [ 13/Jul/11 ]

That is correct.

When the inferencing engine sees something like Object<Type> (type is the name of the type parameter), then it knows that this is a type that has not been resolved yet, and then tries to resolve it based on available type information.

Comment by Andy Clement [ 14/Jul/11 ]

this scenario plays into the same (buggy) area as the groovy++ issue we have with their inferencer. Due to the spaghetti nature of the groovy generic structures, it is hard to work out what groovy wants us to tell it.

I'm not sure we should use terminology like 'Object<Type>' though as that suggests a parameterization of the class Object, which doesn't exist. But I know what you mean because the toString() for these groovy entities will sometimes produce something that reads like that (which doesn't help when trying to understand what groovy wants). The simplistic fix for this breaks one of the existing tests (which deals with a failure to implement an generic interface method).





[GRECLIPSE-1109] As a user, I want to see content assist proposals coming in from DSLDs with a higher relevance Created: 11/Jul/11  Updated: 19/Jul/11  Resolved: 19/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As mentioned on the mailing list, DSLD proposals should have a higher relevancy than regular proposals. In general, I think this is a good idea, but I could also imagine that individual DSLs would want to configure things differently.

Perhaps, there should be some kind of construct in the DSLD file that can configure relevancy.



 Comments   
Comment by Mitko Kolev [ 12/Jul/11 ]

There could be an DSLD elelement (e.g. contentAssistGroup) contributed by one or many pointcuts. Then perhaps iterate the groups (as well as java proposals) on hitting ctrl + space, like in java (showing the dsld groups on the second hit). Maybe a check in the UI to disable it, because it will (should) not be visible in the content assist groups where the java groups are (Java -> Editor -> Content Assist -> Advanced).

Comment by Andrew Eisenberg [ 19/Jul/11 ]

As a first pass, I just hard coded a higher relevance for methods and properties from DSLDs. They should now appear above standard proposals. It would still be nice to be able to tweak their relevance.

I will commit this initial work soon.

Comment by Andrew Eisenberg [ 19/Jul/11 ]

I'm thinking that the work I have done so far is sufficient. Now all DSLDs will be sorted higher than regular proposals. I can still add configurability from within the DSLD itself, but I'm finding it hard to come up with compelling examples and intuitive syntax for this.

Mitko, your idea of having different proposal kinds for different DSLs is a good one, but this would require a completely new implementation of completion processing and would likely take significantly longer to process.

Comment by Andrew Eisenberg [ 19/Jul/11 ]

This issue is complete. See GRECLIPSE-1119 for a proposal to control relevancy from within a DSLD.





[GRECLIPSE-1108] ClasspathContainerTest fails when there are files in ~/.groovy/lib Created: 06/Jul/11  Updated: 11/Jul/11  Resolved: 11/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Test Priority: Minor
Reporter: Rene Scheibe Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ClasspathContainerTest.patch    
Testcase included: yes
Patch Submitted:
Yes
Number of attachments : 1

 Description   

As ~/.groovy/lib is per default contained in the project classpath the test fails.

A patch is included. I removed ~/.groovy/lib from the classpath for the test and converted it to Groovy for better reading.



 Comments   
Comment by Andrew Eisenberg [ 11/Jul/11 ]

Patch looks reasonable and so I applied it. I made a change to undo the preference setting after the test is finished.





[GRECLIPSE-1107] Organize imports: moves package statement after some imports Created: 06/Jul/11  Updated: 31/Oct/11  Resolved: 31/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Formatting
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Aled Sage Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7, mac 10.6, java 1.6.0_24


Number of attachments : 0

 Description   

Sometimes when I organize imports on a groovy class, the package statement (which was previously the first line in the class) is moved to after some of the imports. Obviously this results in subsequent compilation errors.

The same problem has also been observed by several of my work colleagues.


I am using eclipse 3.7.

The groovy features I have installed are:
org.codehaus.groovy.eclipse.feature; 2.5.1.xx-20110628-1600-e37
org.codehaus.groovy.jdt.patch; 2.1.3.xx-20110628-1600-e37
org.codehaus.groovy.17.feature: 2.5.1.xx-20110628-1600-e37
org.codehaus.groovy.18.feature: 2.5.1.xx-20110628-1600-e37


I'll try to pin down a deterministic test case with private code removed, but no luck doing that yet...



 Comments   
Comment by Andrew Eisenberg [ 11/Jul/11 ]

Can you attach a sample? There's not much I can do without this.

Comment by Aled Sage [ 12/Jul/11 ]

Hi, this is presumably a very related test-case...

  1. Create the groovy class foo.Greclipse1107 (as shown below)
  2. Create a simple groovy class foo.bar.Blah
  3. In the file Greclipse1107.groovy, place the cursor after Blah
  4. Do cntrl-space to automatically add the import

The line "import foo.bar.Blah;" is added at the top of the file, before the package statement.

Also note that in this test case doing "organize imports" doesn't add an import for Blah at all.

package foo

class Greclipse1107 {

    public void foo() {
        Blah blah = this
        do {
        } while (blah != null)
       
        return null
    }
}
Comment by Andrew Eisenberg [ 12/Jul/11 ]

Thanks for the test case. The reason why you are seeing this is because the do...while construct is not a valid construct in Groovy. When this construct exists, it breaks the parser. So, when you do content assist, the content assistant can determine that foo.bar.Blah is a missing type, but it doesn't know where to put it, so it gets placed at the top.

If you fix the syntax errors in the code, then content assist works properly.

That's not to say that this isn't a bug in Groovy-Eclipse (it is). Groovy-Eclipse needs to either:

  1. Avoid proposing anything if there is a syntax error like this.
  2. Or, figure out that the import proposal should be placed after the package statement.
Comment by Aled Sage [ 12/Jul/11 ]

Thanks Andrew,

I'd definitely prefer option 2, putting the import after the package statement (and always ensuring the import is only added if it does not already exist).

Certainly when working with Java code in the IDE, I organize imports frequently. If I have errors when making changes to a class, I almost always hit ctrl-shift-o to get rid of any errors caused by missing imports, and then I look at fixing other errors such as incorrect constructs. I presume a lot of other developers are trigger-happy with hitting ctrl-shift-o a lot as well.

Comment by Andrew Eisenberg [ 13/Jul/11 ]

Digging a little deeper into the problem it looks like in this case the syntax error is causing the package statement and any existing imports to be removed from the Antlr AST. This means that the root cause is coming from the error recovery in the grammar.

This is not a piece that I have built myself, so I am assigning this to Andy.

Comment by Andy Clement [ 31/Oct/11 ]

added more recovery, will now cope with code busted like this and not discard the earlier stuff that was successfully parsed. Not fixed in 1.7, only in 1.8.





[GRECLIPSE-1106] IllegalArgumentException when organizing imports on groovy class Created: 06/Jul/11  Updated: 20/Jul/11  Resolved: 20/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Aled Sage Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7, mac, java 1.6.0_24


Number of attachments : 0

 Description   

When I organize imports on a groovy class I sometimes see the
IllegalArgumentException shown below. If I ignore the problem, continue
working on the class, and then try again later it usually works...

java.lang.IllegalArgumentException
at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java:2616)
at
org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2667)
at
org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:205)
at
org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2708)
at
org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1290)
at
org.eclipse.jdt.core.dom.CompilationUnitResolver.convert(CompilationUnitResolver.java:291)
at
org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1201)
at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:801)
at
greclipse.org.eclipse.jdt.core.dom.rewrite.ImportRewrite.rewriteImports(ImportRewrite.java:1065)
at
org.codehaus.groovy.eclipse.refactoring.actions.OrganizeGroovyImports.calculateMissingImports(OrganizeGroovyImports.java:411)
at
org.codehaus.groovy.eclipse.refactoring.actions.OrganizeGroovyImports.calculateAndApplyMissingImports(OrganizeGroovyImports.java:509)
at
org.codehaus.groovy.eclipse.refactoring.actions.OrganizeGroovyImportsAction.run(OrganizeGroovyImportsAction.java:82)
at
org.eclipse.jdt.ui.actions.OrganizeImportsAction.run(OrganizeImportsAction.java:204)
at
org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:279)
at
org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at
org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185)
at
org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109)
at
org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at
org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at
org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
at
org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468)
at
org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786)
at
org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885)
at
org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567)
at
org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508)
at
org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1069)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4124)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1457)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1480)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1465)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1494)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1490)
at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:463)
at
org.eclipse.swt.widgets.Control.doCommandBySelector(Control.java:1051)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5560)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at
org.eclipse.swt.internal.cocoa.NSResponder.interpretKeyEvents(NSResponder.java:68)
at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:587)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5470)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220)
at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2092)
at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2255)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5532)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at
org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:4986)
at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5135)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at
org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:128)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3607)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)


I am using eclipse 3.7.

The groovy features I have installed are:
org.codehaus.groovy.eclipse.feature; 2.5.1.xx-20110628-1600-e37
org.codehaus.groovy.jdt.patch; 2.1.3.xx-20110628-1600-e37
org.codehaus.groovy.17.feature: 2.5.1.xx-20110628-1600-e37
org.codehaus.groovy.18.feature: 2.5.1.xx-20110628-1600-e37


I'm trying to produce a cut-down example class (with proprietary code
removed) - I'll add it here if I can.



 Comments   
Comment by Andrew Eisenberg [ 11/Jul/11 ]

Not much that I can do without a sample. Please provide. If possible, you can send me the proprietary code directly.

Comment by Aled Sage [ 12/Jul/11 ]

removed comment; added to bug 1107 instead...

Comment by Andrew Eisenberg [ 12/Jul/11 ]

Any luck at reproducing this one?

Comment by Aled Sage [ 12/Jul/11 ]

Haven't seen this one again yet...

Comment by Andrew Eisenberg [ 20/Jul/11 ]

Thanks for the test project. Wow. Something is very broken with it. I'll have a look.

Comment by Andrew Eisenberg [ 20/Jul/11 ]

An initial look and this appears to be related to an anonymous class declaration.

Comment by Andrew Eisenberg [ 20/Jul/11 ]

It seems like a combination of the anonymous class and the doc comment on the field assigned to the anonymous class is causing the error. Even without the comment, source positions appear to be incorrect, but the exceptions are not manifested.

Here is a simpler variant of the same problem:

class Foo {
	/** */
	private HashMap m = new HashMap() { }
}
Comment by Andy Clement [ 20/Jul/11 ]

Adjusted positioning setting logic for anonymous inner classes. appears to fix it.





[GRECLIPSE-1105] Types are inferred wrongly using a fluent builder Created: 05/Jul/11  Updated: 13/Jul/11  Resolved: 11/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Mitko Kolev Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.7 (Indigo)


Attachments: Zip Archive TestGroovyEclipse.zip    
Testcase included: yes
Number of attachments : 1

 Description   

Consider the following fluent builder:

public class FluentBuilder {
	private String name;
	private Integer id;
	public FluentBuilder name(String name) {
		this.name = name;
		return this;
	}
	public FluentBuilder id(int id) {
		this.id = id;
		return this;
	}
	public void setName(String name) {this.name = name;}
	public String getName() {return this.name;	}
	public Integer getId() {return this.id;	}
	public void setId(Integer id) {this.id = id;}

	@Override
	public String toString() {
		return "FluentBuilder [name=" + name + ", id=" + id + "]";
	}
}

and the usage class:

import FluentBuilder
import org.junit.Test
import static org.junit.Assert.assertEquals
class Main {
	
	@Test
	public void testBuilder(){
		FluentBuilder builder = new FluentBuilder();
		assertEquals("FluentBuilder [name=name, id=123]", builder.name("name").id(123).toString())
	}
}

After the .name("name") method, the correct type (FluentBuilder) is not inferred (the method name in "id(123)" is underlined).



 Comments   
Comment by Andrew Eisenberg [ 05/Jul/11 ]

As mentioned on the mailing list, it looks like the getter is being inferred instead of the correct method. I'm currently on vacation now, but will have a chance to look at this when I return.

Comment by Andrew Eisenberg [ 11/Jul/11 ]

I tried out your example and could not reproduce exactly what you are seeing. There are no unexpected underlines for me. Then, I went back to your original email message on this and tried the sample you included:


class A {
	String field;
	public A field(String field){
	   this.field = field;
	   return A;

	}

	public void setField(String field){
	   this.field = field;
	}
}

A a = new A();
a.field("value").field

In this case, the second reference to field in the final statement is indeed underlined, when it should not be. I am not sure why I am seeing different behavior on the different examples, when you are not, but this is clearly not correct.

Furthermore, I also see some problems with mark occurrences. In the example above, I select the method id declaration and all references to the field id are highlighted. Then I select the field id declaration and no references are highlighted. This is a related problem.

Comment by Andrew Eisenberg [ 11/Jul/11 ]

OK. I have something working locally. Essentially the fix is this:

  • if a reference is the name of a method call, then search for methods first, before searching for properties and then fields of the same name.
  • if a reference is not the name of a method call, then search for properties and fields first before searching for methods.

This appears to address all of the problems I have described. I will write up a few tests and then commit.

Comment by Andrew Eisenberg [ 11/Jul/11 ]

Committed fix with regression tests. Will be available in next dev build.

Comment by Mitko Kolev [ 11/Jul/11 ]

Hi Andrew,
thank you for the fix, I will check it out (some more complicated cases also) when the build is over. BTW, can you send me a link to the continuous integration you are using?
Regards,
Mitko

Comment by Andrew Eisenberg [ 11/Jul/11 ]

Yes, please let me know if there are any cases that I have missed.

Here is our CI server:
http://bamboo.ci.codehaus.org/browse/GRECLIPSE

And the resulting update sites that are built can be found here:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/

Comment by Mitko Kolev [ 13/Jul/11 ]

Hi Andrew,

I tried to test the stuff you implemented, unfortunately the fluent builder of the library that is used in my company (Apache Camel) is still causing problems. Some elements are underlined because the types are wrongly inferred. Unfortunately this is the case in many productive implementations of the builder.

I invested hours to reproduce the same with simple classes with the same structure, however, with simple structures everything is surprizingly working.

Therefore I attach a sample project with the library and hope that you will see where the actual problem is with the library builder. You have to just import the project in your Eclipse.

The project contains 2 packages:
test with the Camel builder and
simplestructure with the latest state with which I tried to reproduce the library issue.

Comment by Andrew Eisenberg [ 13/Jul/11 ]

I installed your project. So far, it looks like a problem with inferencing of generics, but I am still exploring.

Comment by Andrew Eisenberg [ 13/Jul/11 ]

Yes, this is indeed a generics problem. The underlines go away when I directly use the source of the binary files. I raised GRECLIPSE-1110 to track this. Thanks for the test case.





[GRECLIPSE-1103] [formatter] Ignores 'correct indentation' save action preference Created: 05/Jul/11  Updated: 05/Jul/11  Resolved: 05/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Option to correct indentation (Set via Preferences >> Java >> Save Actions >> Additional Actions) is ignored by the formatter, even though it most certainly has the capability to support it.



 Comments   
Comment by Kris De Volder [ 05/Jul/11 ]

Fix committed.





[GRECLIPSE-1102] Groovy editor is formating the code if the Java/Editor/Save Actions are activated (Format source code not selected) Created: 05/Jul/11  Updated: 05/Jul/11  Resolved: 05/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

See https://issuetracker.springsource.com/browse/STS-1901

Summary:

  • Goto in "Java >> Editor >> Save Actions" preferences
  • enable save actions
  • disable "format on save"
  • have "format edit lines" selected.

Now, even though "format on save" is disabled, Groovy editor will still perform a format on save anyway.

Problem only happens when "format edited lines" is selected, not when "format all lines" is selected.



 Comments   
Comment by Kris De Volder [ 05/Jul/11 ]

Committed a fix.

However, looking at code around bug, I suspect other problems with formatter 'save action' prefs. Will raise other Jira for this.

Comment by Kris De Volder [ 05/Jul/11 ]

Two other Jira for the related bugs:





[GRECLIPSE-1101] recognizing copied nodes in the ast Created: 04/Jul/11  Updated: 01/Nov/11  Resolved: 01/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Minor
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Groovy reorganizes the ast sometimes, copying pieces from here to there (e.g. field initializers copied into ctors). Recognizing when this occurs can be tricky. It should be easy to tag these copied nodes as 'copies', indicating that the original still exists elsewhere in the ast structure. Visitors are then able to recognize and skip the copy, knowing that they will encounter the original elsewhere during their visit.



 Comments   
Comment by Andy Clement [ 01/Nov/11 ]

just dont think we can solve this in a fully satisfactory way. Even if we made all the existing transforms behave, there will be user ones that wont and we cant really force them. revisit if becomes the only way to proceed.





[GRECLIPSE-1100] @Slf4j or @Log on class shows error in static method Created: 03/Jul/11  Updated: 23/Jul/14  Resolved: 23/Jul/14

Status: Closed
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.1Release
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Minor
Reporter: Jim Morris Assignee: Unassigned
Resolution: Fixed  
Labels: wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse 3.6.2
GREclipse 2.5.2.xx-20110630-1100-e36


Attachments: JPEG File screenshot-1.jpg    
Testcase included: yes
Number of attachments : 1

 Description   

Using the @Log or @Slf4j annotation on a class shows an error (red cross) in Eclipse in a static method, but still compiles and runs ok. No error is given in groovyc.

The error shown is

Groovy:Apparent variable 'log' was found in a static scope but doesn't refer to a local variable, static field or class. Possible causes:

Example...

    import groovy.util.logging.Log

    @Log
    public class TestLog {
	static main(args) {
		log.info("args= ${args}") // <-- Error on this line
	}	
    }


 Comments   
Comment by Andy Clement [ 04/Jul/11 ]

This is to be expected. We don't (right now) run ast transforms as part of reconciling - reconciling is what shows you the editor errors. Without the transform running it doesn't know what 'log' is (as it hasn't been added). You can remove these problems by turning off reconciling (in preferences Java>Editor>'Report problems as you type').

Transforms run just fine as part of real compilation which is why it compiles and runs just fine.

Comment by Jim Morris [ 04/Jul/11 ]

Ok, but I am curious why it works for a non static method and only shows the error on a static method?

Also could I write a DSLD to overcome this issue? I wrote a DSLD for the @Slf4j annotation which seems to work for non-static methods.

Thanks

Comment by Andy Clement [ 04/Jul/11 ]

> Ok, but I am curious why it works for a non static method and only shows the error on a static method?

According to this page: http://groovy.codehaus.org/Compiler+Phase+Guide

"As a particular example, Groovy aggressively and statically types the static properties of a class..."

This means static properties are subject to different rules than non-static. Groovyc will give you just the same error if you remove @Log, or in this example:

public class TestLog {
static staticMethod()

{ bar }

def nonStaticMethod()

{ foo }

}

groovyc will give you an error on bar but not on foo. (Non static property references aren't subject to the same aggressive resolution). I have no idea why groovyc behaves in this way, but that is just the info I found which does seem to describe what we are seeing.

> Also could I write a DSLD to overcome this issue? I wrote a DSLD for the @Slf4j annotation which seems to work for non-static methods.

A DSLD is to aid code assist and enable you to remove underlining (which I see as a kind of compiler warning), it isnt for fixing compilation errors. Here, the Log transform is not run and so the log property isn't added early enough and you get the error according to those rules above that I found. the fix would be to run the transform as part of the reconcile compile, something we are considering doing.

Comment by Jesse Docken [ 27/Mar/12 ]

I'm experiencing this issue with all annotations, including @Log4j. It's very visually distracting.

Comment by simon misys [ 19/Jul/13 ]

> the fix would be to run the transform as part of the reconcile compile,
> something we are considering doing.

is there any update to this? this code still shown as an error eclipse kepler.

Comment by Denis Murashev [ 17/Jul/14 ]

Looks like already fixed. (Tested in version 2.9.0.RELEASE)

Comment by Denis Murashev [ 23/Jul/14 ]

Looks like it was already fixed





[GRECLIPSE-1099] Cannot edit a dsld that is in the global_dsld_support folder Created: 30/Jun/11  Updated: 12/Jul/11  Resolved: 11/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Jim Morris Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy support Version: 2.5.1.xx-20110627-1300-e36
Eclipse Version: 3.6.2


Number of attachments : 0

 Description   

This is an odd one.
I have a file called logback.dsld in the global_dsld_support folder. (it works ok).
When I click on it in eclipse it opens it, but it will not let me edit it. I can edit it with an external editor though.

Then after editing it externally If I click on it in eclipse I get the "resource out of sync..." error, even after hitting refresh, and reloading dslds etc.

If I exit Eclipse and restart it then I can click on it and see it, however I still cannot edit it in eclipse.



 Comments   
Comment by Andrew Eisenberg [ 30/Jun/11 ]

Yes, you will have to edit them in an external folder. After editing, you will need to open Preferences -> Groovy -> DSLD and then click 'Recompile'.

These files are meant to be fairly stable and not directly edited. If you do want to edit these files, then I'd recommend that you first copy into a project's source folder, edit there, and then copy back. You can drag and drop from the DSL Support classpath container, but you can only copy back from outside of eclipse.

It's a little more complicated of a workflow than I would like, but this makes it harder to inadvertently mess up existing DSLDs.

I'll try to think of a better way of doing this that retains the safety, but also makes editing easier.

Comment by Andrew Eisenberg [ 11/Jul/11 ]

I made a few changes to the way that the editor is opened for DSLDs coming from outside the workspace. And so they are now editable, but only when opened from the Groovy->DSLD preferences page.

This change also has fixed a few other problems with DSLD editing.

The fix will be available in the next dev build coming from the dev update site:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
or
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

Editing external files is quite finicky, but I think it is behaving much better now. I'll close this issue, but please send me feedback if this is working for you or if you find any other problems with editing.

Comment by Andrew Eisenberg [ 11/Jul/11 ]

done. Please re-open if you still have any problems or see any exceptions in your Error log.

Comment by Jim Morris [ 12/Jul/11 ]

Well I have upgraded to eclipse 3.7, and I think I just got the latest greclipse.
Version: 2.5.2.xx-20110709-1200-e37

When I try to edit the file I get the following exception, also in the package view under Groovy DSL Support both global_dsld_support and plugin_dsld_support show no files, however under the Preferences/Groovy they show up.
What is the need for the Groovy DSL Support in the packages file?

Java.lang.NullPointerException
at org.eclipse.jdt.internal.core.BecomeWorkingCopyOperation.executeOperation(BecomeWorkingCopyOperation.java:46)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.eclipse.jdt.internal.core.CompilationUnit.becomeWorkingCopy(CompilationUnit.java:101)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createFileInfo(CompilationUnitDocumentProvider.java:1000)
at org.eclipse.ui.editors.text.TextFileDocumentProvider.connect(TextFileDocumentProvider.java:478)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.connect(CompilationUnitDocumentProvider.java:1243)
at org.eclipse.ui.texteditor.AbstractTextEditor.doSetInput(AbstractTextEditor.java:4213)
at org.eclipse.ui.texteditor.StatusTextEditor.doSetInput(StatusTextEditor.java:237)
at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.doSetInput(AbstractDecoratedTextEditor.java:1451)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.internalDoSetInput(JavaEditor.java:2563)
at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput(JavaEditor.java:2536)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput(CompilationUnitEditor.java:1395)
at org.codehaus.groovy.eclipse.editor.GroovyEditor.doSetInput(GroovyEditor.java:949)
at org.eclipse.ui.texteditor.AbstractTextEditor$19.run(AbstractTextEditor.java:3200)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756)
at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2642)
at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:3218)
at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:3245)
at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:828)
at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:647)
at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:313)
at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:180)
at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:270)
at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:473)
at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1245)
at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1198)
at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1597)
at org.eclipse.ui.internal.PartStack.add(PartStack.java:493)
at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
at org.eclipse.ui.internal.PartStack.add(PartStack.java:479)
at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:225)
at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:213)
at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:808)
at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:707)
at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:666)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2942)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2850)
at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPage.java:2842)
at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2793)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2789)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2773)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2764)
at org.eclipse.ui.ide.IDE.openEditor(IDE.java:582)
at org.codehaus.groovy.eclipse.dsl.ui.DSLPreferencesPage.edit(DSLPreferencesPage.java:332)
at org.codehaus.groovy.eclipse.dsl.ui.DSLPreferencesPage$DSLListAdapter.customButtonPressed(DSLPreferencesPage.java:179)
at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField.buttonPressed(TreeListDialogField.java:171)
at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField.doButtonSelected(TreeListDialogField.java:392)
at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField.access$2(TreeListDialogField.java:388)
at org.eclipse.jdt.internal.ui.wizards.dialogfields.TreeListDialogField$2.widgetSelected(TreeListDialogField.java:353)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:240)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3588)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3209)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.open(WorkbenchPreferenceDialog.java:215)
at org.eclipse.ui.internal.handlers.ShowPreferencePageHandler.execute(ShowPreferencePageHandler.java:54)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241)
at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:157)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3588)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3209)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)

Comment by Andrew Eisenberg [ 12/Jul/11 ]

Sorry. The build with the fixes didn't go through. There were some problems on the build server. It should be fixed now and I will let you know when the next build is available.

Comment by Andrew Eisenberg [ 12/Jul/11 ]

New builds are available. Please let me know if this fixes your problem.

Comment by Jim Morris [ 12/Jul/11 ]

Yes that latest release did fix both issues. Thanks





[GRECLIPSE-1098] plugin_dsld_support disappears when using groovy 1.8 Created: 29/Jun/11  Updated: 11/Jul/11  Resolved: 11/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Jim Morris Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy support Version: 2.5.1.xx-20110627-1300-e36
Eclipse Version: 3.6.2


Number of attachments : 0

 Description   

With 1.7 groovy the plugin dsld support folder is there and works, when I click the use 1.8, after a restart it disappears.
Also my projects lose their dsld support enabled, and checking them does not stick.



 Comments   
Comment by Andrew Eisenberg [ 29/Jun/11 ]

Thanks for pointing this out. The DSL support folder is missing on the 3.6 build for Groovy 1.8.

A work around is to copy the plugin_dsld_support folder from the org.codehaus.groovy_1.7.10.xx-20110627-1300-e36 plugin to the org.codehaus.groovy_1.8.0.xx-20110627-1300-e36. But, this will not fix the problem for other users. I may need to re-spin the release build.

This folder is available on Eclipse 3.7, just not Eclispe 3.6.

Comment by Andrew Eisenberg [ 30/Jun/11 ]

I fixed the org.codehaus.groovy 1.8 bundles on the update site. This will mean that people who have not already installed 2.5.1 will not have a problem, but people who have already installed will have the same problem that you have. They will either need to copy over the plugin_dsld_support file or uninstall and reinstall.

I am still deciding if we should respin the build.

Comment by Andrew Eisenberg [ 11/Jul/11 ]

Decided not to respin the build. No complaints so far. Anyone who had inadvertently installed the bad version is probably someone who tracks head closely and will have no problem moving to a dev build.





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1096] Allow access to parameters of enclosing calls in DSLD Created: 25/Jun/11  Updated: 27/Jul/11  Resolved: 27/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Minor
Reporter: Carsten Mjartan Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The Gradle DSL allows the following method call, where the delegate type of the given closure is given as 'type' parameter:

task myJar(type: Jar) {
   // code delegating to Jar class
}

It would be nice to have access to that 'type' parameter for usage with 'delegateTo' inside the closure.



 Comments   
Comment by Andrew Eisenberg [ 25/Jun/11 ]

Consider this for the 2.5.2 release.

Comment by Andrew Eisenberg [ 25/Jun/11 ]

This might be possible already, but the syntax is not entirely friendly.

Comment by Andrew Eisenberg [ 22/Jul/11 ]

Considering this kind of syntax:

enclosingCall(name("myJar") & hasArgument(name("type") & bind(types : value()))).accept {  
  // 'types' is bound to a collection of one element that contains the Groovy AST node that is the value of the named argument (in this case 'Jar')
  types.each { delegatesTo it }
}
Comment by Andrew Eisenberg [ 22/Jul/11 ]

A note for myself, that it is important to distinguish between the parameters of the method declaration and the arguments in the method call. Perhaps, hasParameter should be renamed to hasArgument.

Comment by Andrew Eisenberg [ 22/Jul/11 ]

Also, this pointcut will never match if the enclosing call does not use named arguments.

Comment by Andrew Eisenberg [ 27/Jul/11 ]

Committed with regression tests.





[GRECLIPSE-1094] Ability to mark DSL contributions as deprecated Created: 24/Jun/11  Updated: 19/Jul/11  Resolved: 19/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As DSLD support evolves, it will be necessary to deprecate certain pointcuts. We will need to ensure that they remain available, but we will need some UI affordance to tell the user that they are deprecated and discouraged from use.



 Comments   
Comment by Andrew Eisenberg [ 24/Jun/11 ]

It should be easy enough to add a new flag in the method and property contributions so that a contribution should be deprecated.

Comment by Andrew Eisenberg [ 19/Jul/11 ]

This will become important as we start changing the DSLD language itself.

Comment by Andrew Eisenberg [ 19/Jul/11 ]

I have a prototype now working locally. I need to add some tests and then I will commit.

Comment by Andrew Eisenberg [ 19/Jul/11 ]

Now working with regression tests





[GRECLIPSE-1093] Save actions: semicolon & trailing whitespace removal Created: 22/Jun/11  Updated: 09/Jul/11  Resolved: 09/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: New Feature Priority: Minor
Reporter: Rene Scheibe Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File all-in-one.patch     GZip Archive patches-GRECLIPSE-1093.tar.gz     Text File whitespace_config.patch    
Number of attachments : 3

 Description   

There should be 2 configurable save actions to:

  • remove unnecessary semicolons
  • remove trailing white spaces


 Comments   
Comment by Andrew Eisenberg [ 03/Jul/11 ]

First patch sent to me via email from Rene.

Comment by Andrew Eisenberg [ 03/Jul/11 ]

Rene,

Can you please recreate the patch using the following instructions:

1. Open Eclipse
2. Select all changed projects
3. Right click -> Team -> Create patch...
4. Select clipboard/file/workspace (whichever is most appropriate)
5. Next
6. In the advanced options page, select "Workspace" as the patch root
7. Finish

This assumes that you have imported the projects into eclipse and connected them to an svn repository.

A patch created using this mechanism is the easy to apply in a multiproject setting. Otherwise, it is next to impossible to apply the patch properly without my having to re-fetch from the repository.

Comment by Rene Scheibe [ 04/Jul/11 ]

The patch in the Eclipse multi-project patch format.

On the command line a simple patch -p0 < all-in-one.patch with the standard patch format is also possible.

Comment by Kris De Volder [ 05/Jul/11 ]

Andrew asked me to take a look at the patch...

Took a long a hard look, but I can't apply the patch as is.. it has some conflicts for me in "OrganizeGroovyImportsCleanup". It looks like you have renamed that class and there have been some changes already to that class since you created the patch.

There are also some conflicts in GroovyCleanupPostSaveListener. They seem related to same rename plus some purely cosmetic changes you made to a for loop.

For future reference, please try to avoid making non-essential changes like formatting changes, pure 'style' changes, and wide sweeping rename refactorings, etc.

It is not that I really disagree that these things are better getting fixed (definitely 'indentend' is not a good name , however, the larger a patch, the harder it is to apply and evaluate. So for patches it is generally best you try to avoid making changes unless directly related to the issue you are trying to fix.

Hate to ask this, but could you try preparing a new patch after merging in latest changes from SVN?

Since Andrew's on vacation now, the SVN should be relatively quiet and even if the patch is a bit largish, I'd have a good chance of applying it, if done quickly after you created it.

Kris

Comment by Rene Scheibe [ 05/Jul/11 ]

I'll prepare 2 new patches (one for the new feature, one for cleanups). When submitting my patch it was up-to-date with the latest SVN version.

Comment by Rene Scheibe [ 05/Jul/11 ]

I have seen your comment in GroovyCleanupPostSaveListener:
// FIXKDV: can we support this:
// CleanUpConstants.FORMAT_REMOVE_TRAILING_WHITESPACES)) ?

Yes, we can. I already had prepared this for this feature. It will be included in this feature (but not yet in the current patches).

Comment by Rene Scheibe [ 05/Jul/11 ]

Updated patches.

GRECLIPSE-1093_cleanup1.patch contains only cleanups.

GRECLIPSE-1093_formatter_remove-semicolons.patch only contains the files added/changed for the new feature.

Comment by Andrew Eisenberg [ 06/Jul/11 ]

Assigning to Kris since I am not currently able to look at this.

Comment by Kris De Volder [ 06/Jul/11 ]

Hi Renee,

Thanks for the new patches. Yes I understand that your first patch was based on the current head when you made it. The problem was changes that happened after you made the patch.

I'll have a look right away at these new patches, before something else changes .

Kris

Comment by Kris De Volder [ 06/Jul/11 ]

Hi Renee,

Looking through the various changes in the patch (only the issue patch so far, not the cleanup fixes)... Some comments.

Firt off, it looks much cleaner and leaner so that is good. But I think in the cut-down there must be some crucial piece(s) gone missing. Here are some things I noticed:

1) When I run it the one test added to the formatter suite that tests 'semi colon removal enabled' scenario is failing.

2) There's a SemiColonRemover class which seems to be the main thing that is meant to performs semicolon removal
(duh).
But as far as I can tell it isn't used by anything. So it isn't too surprising the test under 1 is failing.

3) There's a 'SemiColonRemoverTest' you made. But its not hooked up to the main test suite 'AllRefactoringTests'.
That's not a big deal. I can add this myself.

Issue 1,2 seems to mean we may need another patch with the missing pieces. However, I'll go look for them in the cleanup patch first. With any luck, maybe I can find the missing bits there

Comment by Kris De Volder [ 06/Jul/11 ]

Ok, I see, the idea of splitting up between 'cleanups' and 'essential' bits was a good one, but it looks like the patches really both contain essential bits and cleanups. So I can't really consider them as separate patches.

Some bits found in second 'cleanup patch' seems to be the preferences pages and their hookups, and hookup code for the semicolon remover into the 'GroovyBeautifier'.

Comment by Kris De Volder [ 06/Jul/11 ]

Hi Renee,

Unfortunately, I can't accept the patches as is, because they break the existing Groovy formatter. Here is an example that shows the problem:

package gtunez

class Song {

def x;
	def y;
	
			def slop()
{
				foo()  ;   
           		bar();
		slop();
	}

	static constraints = 
	{
	}
}

The problem, I believe is how the edits for semicolon removal are being combined with other edits by the formatter.

You have to be aware that the Eclipse TextEdit framework doesn't like it if edits with overlapping text regions are being combined together. This will result in an exception and all edits will be ignored.

You should add more tests (with some more complex examples like the one I have above).

There's a flag DEBUG_EDITS in GroovyBeatifier that you can turn on. If you try the example above and format it with the semicolon removal turned on, you will notice that the formatter doesn't do anything and an exception stacktrace is being printed on console.

Comment by Kris De Volder [ 06/Jul/11 ]
org.eclipse.text.edits.MalformedTreeException: Overlapping text edits
	at org.eclipse.text.edits.TextEdit$InsertionComparator.compare(TextEdit.java:121)
	at java.util.Collections.indexedBinarySearch(Collections.java:319)
	at java.util.Collections.binarySearch(Collections.java:307)
	at org.eclipse.text.edits.TextEdit.computeInsertionIndex(TextEdit.java:796)
	at org.eclipse.text.edits.TextEdit.internalAdd(TextEdit.java:781)
	at org.eclipse.text.edits.TextEdit.addChild(TextEdit.java:335)
	at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyBeautifier.removeUnnecessarySemicolons(GroovyBeautifier.java:353)
	at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyBeautifier.getBeautifiEdits(GroovyBeautifier.java:71)
	at org.codehaus.groovy.eclipse.refactoring.formatter.DefaultGroovyFormatter.format(DefaultGroovyFormatter.java:131)
	at org.codehaus.groovy.eclipse.refactoring.actions.FormatGroovyAction.run(FormatGroovyAction.java:71)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:279)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.ui.actions.RetargetAction.runWithEvent(RetargetAction.java:230)
	at org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPluginAction.java:234)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
	at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
	at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3588)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3209)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Comment by Kris De Volder [ 06/Jul/11 ]

BTW: Forgot to mention something. If you prepare a new patch with bugfix, please don't use the funny test method names with spaces in them. I get exceptions when I try to add such tests to a larger test suite, so I had to rename all those methods before I could hookup the test suite from the RefactoringTestSuite.

Comment by Rene Scheibe [ 06/Jul/11 ]

I know about the issue with overlapping TextEdits. Creating chains of edits for all steps of the formatter as currently done in the plugin is not a good idea. I will apply the MultiTextEdit after each step and run the next step on the result document of the previous one.

The "funny" test names are for better readability. Haven't had real issues with them (only the JUnit Eclipse plugin cannot find the method as it's only targeted for Java). But I will rename them.

Comment by Andrew Eisenberg [ 06/Jul/11 ]

Hi Rene,

I would be careful about applying a MultiTextEdit halfway through a format operation since this will probably confuse the Undo manager. I haven't tried this so I don't know, and this is why I say 'probably'. But it is something to keep in mind and make sure is not broken.

As for spaces in test names in the JUnit plugin. There are two ways to fix that, and neither are easy. One would require using AspectJ and STS, and the other would require shipping with a second feature patch. It is something on the list (and quite a few bugs are already raised against it).

Comment by Rene Scheibe [ 06/Jul/11 ]

Yes I know. Undo operations are on my list to check how they are done.

I saw the approach of applying TextEdits halfway in DefaultGroovyFormatter#format. I creates a new document only for applying the different TextEdits and then creates a big ReplaceEdit out of it at the end. Something like this will do.

The GroovyBeautifier is a mess at the moment. And also the DefaultGroovyFormatter with leaking its formatOffset and formatLength into the GroovyBeautifier and GroovyIndentation. The goal should be to have the different aspects of formatting much more modularized. Let's see what I can do.

I will also have a look at how it's done for Java.

Comment by Kris De Volder [ 06/Jul/11 ]

Undo won't be a problem. The formatter, in the end, takes all the changes and turns them into a one shot change that replaces the whole file at once with a completely new contents. (Not nice, but that's what it does).

For Rene's changes, I think, that they wouldn't conflict with other edits... since they modify only things that other formatter edits tend to leave alone (i.e. semicolons).

The problem, I think, is that Rene has first smashed all his edits together into one multi text edit and then adds that big edit to the existing ones. If, instead, he'd just add all his little edits one-by-one to the existing ones, I don't think there'd be an overlapping text-edits problem.

Re the big mess... I hear you Renee, that formatter code is indeed a big mess, no argument there. The problem is that rewriting it from scratch would take a lot of effort, and we don't really have time for it.

Are you volunteering for the job?

Comment by Rene Scheibe [ 07/Jul/11 ]

I will have a look at it for sure. No guarantee that I'll tackle it.

You could give some points/proposals how you'd like the formatter to be designed.

Comment by Kris De Volder [ 07/Jul/11 ]

What people seem to want, is that it as much as possible emulates and follows the JDT formatter and then adds in Groovy specific things. So the 'base-line' should be JDT formatter and all its settings.

This is a big job however.

Anyhow, let's focus on the issue at hand. If you can try to get the bug I found in your patch fixed we can give it another try at putting that patch in.

Comment by Rene Scheibe [ 07/Jul/11 ]
  • added unnecessary semicolon removal to Formatter (can be configured)
  • added unnecessary semicolon removal as Save Action (can be configured)
  • added trailing whitespace removal as Save Action (can be configured)
  • removed empty "Refactoring" preference page
  • refactored existing cleanups to derive from AbstractGroovyCleanUp (contains pre- and post-condition check)
  • tons of minor cleanup

new files

ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/SemicolonRemover.java
ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/WhitespaceRemover.java
ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/preferences/SaveActionsPreferenceInitializer.java
ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/preferences/SaveActionsPreferencePage.java
ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/AbstractGroovyCleanUp.java
ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/TrailingWhitespacesCleanUp.java
ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/UnnecessarySemicolonsCleanUp.java
ide-test/org.codehaus.groovy.eclipse.refactoring.test/resources/Formatter/Formatter_Test_semicolon_removal_disabled.txt
ide-test/org.codehaus.groovy.eclipse.refactoring.test/resources/Formatter/Formatter_Test_semicolon_removal_enabled.txt
ide-test/org.codehaus.groovy.eclipse.refactoring.test/src/org/codehaus/groovy/eclipse/refactoring/test/formatter/SemicolonRemoverTests.groovy
ide-test/org.codehaus.groovy.eclipse.refactoring.test/src/org/codehaus/groovy/eclipse/refactoring/test/formatter/WhitespaceRemoverTests.groovy

deleted files

ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/ui/preferences/RefactoringPreferencePage.java

renamed & modified files

ide-test/org.codehaus.groovy.eclipse.core.test/src/org/codehaus/groovy/eclipse/core/ClasspathContainerTest.java -> ClasspathContainerTest.groovy
ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/GroovyImportsCleanup.java -> GroovyImportsCleanUp.java

modified files (files marked with an ! are the most important ones)

! base/org.codehaus.groovy18/src/org/codehaus/greclipse/GroovyTokenTypeBridge.java
! base/org.codehaus.groovy/src/org/codehaus/greclipse/GroovyTokenTypeBridge.java
  ide/org.codehaus.groovy.eclipse.core/src/org/codehaus/groovy/eclipse/core/GroovyCoreActivator.java
! ide/org.codehaus.groovy.eclipse.refactoring/plugin.xml
  ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/DefaultGroovyFormatter.java
  ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/FormatterPreferences.java
  ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/FormatterPreferencesOnStore.java
! ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/GroovyBeautifier.java
! ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/GroovyDocumentScanner.java
  ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/GroovyFormatter.java
! ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/IFormatterPreferences.java
  ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/JavaProjectPreferences.java
  ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/lineWrap/CorrectLineWrap.java
  ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/lineWrap/NextLine.java
  ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/formatter/lineWrap/SameLine.java
! ide/org.codehaus.groovy.eclipse.refactoring/src/org/codehaus/groovy/eclipse/refactoring/PreferenceConstants.java
! ide/org.codehaus.groovy.eclipse.ui/plugin.xml
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/GroovyPlugin.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/preferences/AskToConvertLegacyProjects.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/preferences/CompilerPreferencesPage.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/preferences/DebuggerPreferencesPage.java
! ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/preferences/FormatterPreferenceInitializer.java
! ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/preferences/FormatterPreferencesPage.java
! ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/preferences/PreferenceInitializer.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/DelegatingCleanUpPostSaveListener.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/FormatAllGroovyAction.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/FormatGroovyAction.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/FormatKind.java
! ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/GroovyCleanupPostSaveListener.java
! ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/GroovyCodeFormatCleanUp.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/GroovyRefactoringAction.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/GroovyRenameAction.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/GroovyRenameLinkedMode.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/OrganizeGroovyImportsAction.java
  ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/refactoring/actions/RenameDispatcherAction.java
  ide-test/org.codehaus.groovy.eclipse.refactoring.test/resources/Formatter/Formatter_Test_Indent_Remove_WhiteSpace_IndentEmpty.txt
  ide-test/org.codehaus.groovy.eclipse.refactoring.test/resources/Formatter/Formatter_Test_Indent_Remove_WhiteSpace.txt
! ide-test/org.codehaus.groovy.eclipse.refactoring.test/src/org/codehaus/groovy/eclipse/refactoring/test/AllRefactoringTests.java
  ide-test/org.codehaus.groovy.eclipse.refactoring.test/src/org/codehaus/groovy/eclipse/refactoring/test/formatter/GroovyDocumentScannerTests.java
! ide-test/org.codehaus.groovy.eclipse.refactoring.test/src/org/codehaus/groovy/eclipse/refactoring/test/formatter/TestFormatterPreferences.java
! ide-test/org.codehaus.groovy.eclipse.refactoring.test/src/org/codehaus/groovy/eclipse/refactoring/test/TestPrefInitializer.java
Comment by Kris De Volder [ 08/Jul/11 ]

I committed the patch.

There still an outstanding issue that the trailing spaces cleanup prefs are, in this patch, on a Groovy only page. But it should take them from JDT instead.

Comment by Rene Scheibe [ 08/Jul/11 ]

"Remove trailing whitespaces" is now configured via Java instead of on a the Groovy "Save Actions" preference page.

Comment by Kris De Volder [ 09/Jul/11 ]

OK, I think this looks good. Applied the patch.

Comment by Kris De Volder [ 09/Jul/11 ]

Resolving issue. Thanks Renee!





Proposed changes to DSLD syntax (GRECLIPSE-1120)

[GRECLIPSE-1092] Content assist for method calls with named arguments Created: 21/Jun/11  Updated: 28/Sep/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.2.Release

Type: Sub-task Priority: Major
Reporter: Kohsuke Kawaguchi Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Oftentimes in Groovy DSL one defines a Java signature like foo(Map,Closure) and invoke this like "foo(abc:1,def:2)

{...}

".

Markup builders use this extensively, and DSLD scripts themselves use this in defining methods and properties, like these:

method isStatic: true, name: prop.name, params: [blank:Boolean], useNamedArgs:true
method isStatic: true, name: prop.name, params: [creditCard:Boolean], useNamedArgs:true
method isStatic: true, name: prop.name, params: [email:Boolean], useNamedArgs:true

Now, I'd like to be able to provide auto-completion for those map parameter names ("isStatic", "name", and "params" in above example.) I know the expected types of these, which parameters are mandatory, etc.



 Comments   
Comment by Andrew Eisenberg [ 19/Jul/11 ]

How about some syntax like this:

enclosingCall(bind( params : hasNamedParameter("isStatic"))) .accept {
    // params is bound to a collection of Groovy AST expression nodes and is accessible in this body
    params.each {
        // ... propose something
    }
}

I am considering changing the syntax of DSLDs somewhat (while still maintaining backwards compatibility) and I think this style fits in nicely with what you are looking for. Does this work for you?

Comment by Kohsuke Kawaguchi [ 22/Jul/11 ]

Maybe I just need more caffeine but I'm not sure how that proposed syntax works. The first level of content assist for me is to provide possible parameter names (such as "isStatic", "name", and "params".) I'm not seeing where I specify that completion.

The second level of content assist is type, javadoc, and other stuff like that for each parameter name. Maybe your syntax is designed more for this, but then I don't get why "params" is a collection and not singular.

Please see http://youtrack.jetbrains.net/issue/IDEA-71141 , which tracks similar issue I reported for IntelliJ IDEA for possible inspirations.

Comment by Andrew Eisenberg [ 22/Jul/11 ]

I see what you are talking about now. The sample above would allow you to provide different kinds of proposals depending on what named parameters exist. I was confusing your requirement with the one specified in GRECLIPSE-1096. But now I see that you are asking for something different.

There are several pieces that need to be fit together in Groovy-Eclipse before we can have exactly what you are asking for:

  • DSLD syntax improvement. In the linked IntelliJ issue, Peter mentioned using something like allowing the 'method' method to use both params and namedParams. This is something that we had discussed together privately, and is probably a direction that DSLD will go in. So, you would be able to do something like this:
    method name:"foo", params:[required1:Object, required2:Object], namedParams:[optional1:Object, optional2:Object]
    
  • Content assist improvement: named arguments shouldn't be added automatically by content assist, but rather the user will get a list of named argument possibilities to add and can choose one to fill in if desired. So, for example, content assist at 'here' would propose fourth and fifth. It should also be smart enough to know that only named parameters can be there, so it would not propose fff at that location.
    def fff
    myMethodCall(first:1, second:2, third:3, f/*here*/) 
    
  • Hovers/JavaDoc for individual named args (I think you are asking for this, but even if you are not this would still be something nice to have). This might need DSLD syntax enhancement so that we can associate docs with a named parameter. Also, this will need a bit of internal futzing around since Groovy-Eclipse (and JDT in general) only wants to associate Doc hovers with proper declarations (ie- Field, Method, Class,...).

Is this something more like what you are looking for? I'm happy to look at alternate syntaxes if you have something better.

Comment by Andrew Eisenberg [ 09/Sep/11 ]

OK, I have some progress here. I probably should have opened another issue for this piece.

Named parameters are now available as content assist proposals. For example, this is the method contribution:

method name: "foo", params: [blank:Boolean, other:String], useNamedArgs:true

This will show the potential named parameters when doing content assist here:

foo(<**>)

and it will only propose the arguments that are still available. In the above example, both arguments will be proposed, and below, only other will be:

foo(blank:true, <**>)

Like method proposals, Groovy-Eclipse will attempt to guess some reasonable answers based on local context and provide them as auxiliary proposals.

Some caveats:

  1. We don't do prefixes yet. So, foo(blank:true, oth<**>) will not show any named argument proposals.
  2. In some cases the parser breaks and we can't provide any meaningful information. See GRECLIPSE-1192.

I probably won't do 1. yet. I will work on the ability to specify some named and some non-named parameters.

Comment by Kohsuke Kawaguchi [ 12/Sep/11 ]

Apologies for being late. Yes, your 22/Jul/11 comment is spot on, and glad to hear that there's a progress on this.

I do worry a bit about the params: [blank:Boolean, other:String] portion of the syntax, as it doesn't seem to be extensible toward possible future additions such hovers/javadoc.

Looking forward to being able to play with this.

Comment by Andrew Eisenberg [ 14/Sep/11 ]

Doc hovers for parameters is not an easy thing since there is no analog in JDT. It may be quite a difficult thing to implement, and it will not be available for 2.5.2 anyway. I'll create a new issue for this piece.

Comment by Andrew Eisenberg [ 14/Sep/11 ]

I just committed a bit more of the solution here that should close off this feature request. I changed things a bit from the way I previously described things.

Now, method contributions support 2 new parameters: namedParams and optionalParams. Their syntax is the same as params. Here is a description of what they do:

  • params: the regular non-named parameters that will always show up in content assist when selecting a method
  • namedParams: parameters that will always show up in content assist as a name parameter after all of the regular parameters. If invoking content assist inside of a method declaration, namedParams will show up only if they are not already used inside of this call site.
  • optionalParams: these parameters do not show up in content assist for method calls. They only show up when invoking content assist inside of a call site.

Here is an example:

DSLD:

method name: "foo", 
       params: [aaa:Boolean, bbb:String], 
       namedParams: [ccc:Boolean, ddd:String], 
       optionalParams: [eee:Boolean, fff:String]

Groovy script content assist invocation:

fo<**>

Result of invocation (actual text written will vary based on context). Notice that only regular params and named params are displayed:

foo(aaa, bbb, ccc:__, ddd:__)

Content assist invocation again will display eee, and fff:

foo(aaa, bbb, ccc:__, ddd:__, <**>)

Content assist invocation again will now display ccc, ddd, eee, and fff:

foo(aaa, bbb, <**>)

This new feature will be available in the next build.

Comment by Andrew Eisenberg [ 28/Sep/11 ]

Everything that I plan on being available is now available and ready for the 2.5.2 build.





[GRECLIPSE-1090] Problem with InheritConstructors AST transform in a maven project Created: 20/Jun/11  Updated: 07/Jul/11  Resolved: 28/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Maven integration
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File gre1090.tgz    
Number of attachments : 1

 Description   

From the mailing list:

I am getting the following error in Eclipse (using the Groovy Compiler plugin version 1.8.0.xx-20110615-1900-e36, installed from: http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/) when I try to build projects (Maven based, but using the Groovy Nature) that use annotations, such as @InheritConstructors on .groovy files:

> Groovy:Not an ASTTransformation: org.codehaus.groovy.transform.InheritConstructorsASTTransformation declared by groovy.transform.InheritConstructors: klass=class org.codehaus.groovy.transform.InheritConstructorsASTTransformation loaderForKlass=java.net.URLClassLoader@279d9a84 ASTTransformation.class loader=org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@c58f769 SerializableObservables.groovy

The code that caused the above error is pretty simple, and basically looks like this:

public class SerializableObservables {
@InheritConstructors
public static class SerializableObservableList extends ObservableList implements Serializable {}
}

Is there something else I should be be doing to use Eclipse and Groovy 1.8.0 properly?

Originally, I had thought that this problem has come around since the user had 2 versions of Groovy on the classpath. I tried to recreate this problem naively inside of Eclipse (ie- just using the AST transform, but not using maven), but could not. My guess is that this has something to do with incremental compilation when the original class files were produced during a maven build.



 Comments   
Comment by Alex Heneveld [ 21/Jun/11 ]

I'm having the same problem as Andrew (not surprising as we are working
on the same codebase). I've tried a few things which have not helped
but give a bit more info. Some observations:

  • NO PROBLEM to occur with just groovy, groovy-eclipse, and eclipse
    classic (no maven)
  • PROBLEM intermittent when we've added maven, gmaven and groovy.m2eclipse
  • PROBLEM still intermittent when we've switched to the
    eclipse-groovy-compiler
  • PROBLEM still intermittent with org.codehaus.groovy_1.7.10.xx plugins
    are REMOVED (so it isn't an issue with multiple org.codehaus.groovy
    plugins... didn't think so but just confirming)
  • PROBLEM happens even in NON-MAVEN groovy project when there is another
    groovy project using maven

Following on from this last one, which is odd in light of the first one,
because it suggests some build cheese is being introduced by a maven
build, and then affecting a non-maven build. Say we have two unrelated
groovy projects:

(A) groovy-not-maven
(B) groovy-with-maven

We also have a third maven non-groovy project which is a dependency of B
(giving pure-java interfaces); haven't tested whether the problem
happens without this.

(C) non-groovy-with-maven

I can reliably do the following sequence:

1) have (A), (B), (C) open, problem showing in (A) + (B).
2) close (B+C), clean (A), problem still showing
3) restart eclipse, clean (A), problem gone
4) open (B+C), clean all, no problems
5) clean all again, eventually (usu between 1 and 5 builds later) the
problem appears in (B) only
6) clean all again, problem now crops up in (A) and (B)
7) goto 6, or goto 1

So pretty sure it is some sort of caching issue introduced by the maven
builder which confuses itself subsequently, then subsequent to that
confuses the non-maven builder.

It is sometimes possible to make the problem go away by adding a
GROOVY_LIBRARY container, but it comes back, and then removing the
container can make it go away, though it comes back.

Does this help narrow it down? As Andrew describes, it could be our
Maven set-up, but it is nothing out of the ordinary (apart from using
groovy 1.8). (Of course it could be some other bug entirely, just
seeming to manifest itself here, but let's hope not.)

My guess would be the compiler starts using a JAR in the build path from
Maven which is incompatible with a type from a JAR being used by the
annotation processor, then caching that. As in maybe the builder is
checking for the ASTTransformation from the org.codehaus.groovy plugin,
but compiler starts using the groovy-all.jar from the ~/.m2/ path.

We are happy to help debug however we can. Thanks for any assistance.

Alex

Comment by Andy Clement [ 21/Jun/11 ]

Hi,

If you are able to attach a project (or projects) that have the problem, that would really help diagnose the issue.

Comment by Alex Heneveld [ 23/Jun/11 ]

So far attempts to refactor to isolate the problem have failed, i.e. the projects worked.

It is proprietary code so we can't send the actual projects. We'll try some more to isolate it.

Comment by Alex Heneveld [ 28/Jun/11 ]

sample project which manifests the bug

Comment by Alex Heneveld [ 28/Jun/11 ]

attachment gre1090.tgz contains two maven projects, akin to (B) and (C) in the write-up above. extracting this and running `mvn clean install` in the root runs fine. importing the maven projects into Eclipse, build clean, and the error above occurs (for us; hopefully for you also). edit the AnImplSub2 class by uncommenting the constructor and removing the @InheritConstructor annotation, and the error goes away. put it back, the error comes back, etc. cheers.

Comment by Alex Heneveld [ 28/Jun/11 ]

we are getting the same error with @EqualsAndHashCode(includeFields=true)

Comment by Andy Clement [ 28/Jun/11 ]

thanks for the testcase, I'll take a look

Comment by Andy Clement [ 28/Jun/11 ]

very useful testcase, thanks again.

The problem is due to maven monkeying with the context classloader when building projects. The transform loader used by us to load transform classes is configured to include the project classpath and have its parent as the context classloader. This works fine normally, the context classloader is the 'eclipsey' one that can find all our eclipse artifacts (like built in transforms shipped with groovy). In the problem case here maven has stepped in and setup a 'ClassRealm' classloader as the context classloader. This means our transform loader finds the InheritConstructorsASTTransformation in the maven classloader but the compiler is looking for types that extend ASTTransformation (that has been loaded by the eclipsey loader). This means the Inherit... looks like it isn't a transform because the ASTTransformation class in its hierarchy will have been loaded by a different loader. We can address this by avoiding using the context classloader, then the transform will be loaded by the same loader as the ASTTransformation class.

fixed

Comment by Andy Clement [ 30/Jun/11 ]

latest dev builds include the proposed fix, let me know if you have problems with it.

Comment by Alex Heneveld [ 07/Jul/11 ]

works a treat. cheers.





[GRECLIPSE-1089] Launch configurations are being recreated when copies should be used instead Created: 17/Jun/11  Updated: 07/Oct/11  Resolved: 07/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.5.0Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As described in http://stackoverflow.com/questions/6380589/why-does-eclipse-keep-creating-a-new-run-configuration a new copy of a launch configuration is being created when it shouldn't. Rather, an old copy should be created. I have not verified this bug, but I am reporting it anyway so it doesn't fall off the radar before the release.



 Comments   
Comment by Andrew Eisenberg [ 22/Jun/11 ]

This is not a bug that affects launch configurations in 3.7 only. It affects earlier versions as well. Essentially, new launch configurations are being created when an old one should be used instead.

Updating title to reflect this.

Comment by Andrew Eisenberg [ 07/Oct/11 ]

I have changed Groovy launch configuration searching to use the same heuristic as the Java launch configuration does. Now, the Groovy launch config looks for a config with the same project and main type name. If a match is found, then it is used. If multiple matches are found, then the user can choose between them.





[GRECLIPSE-1088] As a user I want own auto format option for groovy closures to set position of opening braces Created: 16/Jun/11  Updated: 02/Oct/12  Resolved: 02/Oct/12

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.5.0Release
Fix Version/s: 2.7.2.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

From: https://issuetracker.springsource.com/browse/STS-1842

Currently there are no auto format options for groovy closures. This is major issue for using auto format option while saving. At least option to set position of opening braces for groovy closures would be nice feature.



 Comments   
Comment by Andrew Eisenberg [ 02/Oct/12 ]

Don't understand the requirements for this one. We already have an option for choosing where the opening curly brace should go.





[GRECLIPSE-1087] ImmutableException when compiling Grails core using Gradle integration Created: 16/Jun/11  Updated: 17/Jun/11  Resolved: 16/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Critical
Reporter: Graeme Rocher Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I'm using STS 2.7 M2 with the GroovyEclipse 1.8 compiler and the Grails source code imported via the Gradle integration. Everything works fine except the class GrailsParameterTests fails to compile with:


Description	Resource	Path	Location	Type
General error during class generation: org.codehaus.jdt.groovy.internal.compiler.ast.ImmutableException

org.codehaus.jdt.groovy.internal.compiler.ast.ImmutableException
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTAnnotationNode.setAllowedTargets(JDTAnnotationNode.java:103)
	at org.codehaus.groovy.vmplugin.v5.Java5.configureAnnotationFromDefinition(Java5.java:230)
	at org.codehaus.groovy.vmplugin.v5.Java5.configureAnnotation(Java5.java:240)
	at org.codehaus.groovy.classgen.AnnotationVisitor.visit(AnnotationVisitor.java:81)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotation(ExtendedVerifier.java:166)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotations(ExtendedVerifier.java:115)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitConstructorOrMethod(ExtendedVerifier.java:76)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitMethod(ExtendedVerifier.java:72)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1149)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitClass(ExtendedVerifier.java:60)
	at org.codehaus.groovy.control.CompilationUnit$6.call(CompilationUnit.java:835)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1146)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:586)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:564)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:541)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1431)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:827)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:680)
	GrailsParameterMapTests.groovy	/grails-head.grails-test-suite-uber/src/test/groovy/org/codehaus/groovy/grails/web/servlet/mvc	line 0	Java Problem

If I exclude GrailsParameterMapTests from the Build path then another file throws the same exception

Anyway it would be nice if this was fixed as I would like to use GroovyEclipse/STS as the IDE for the Grails source code



 Comments   
Comment by Andy Clement [ 16/Jun/11 ]

Hi Graeme - fixed this earlier this week when Jeff reported it to me. You need a dev build of groovy-eclipse, from http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

Comment by Graeme Rocher [ 17/Jun/11 ]

Thanks Andy, I update the the latest snapshot, but now I have hundreds of compilation errors. With lots of "BuildSettings cannot be resolved as a type"

Any ideas?

Comment by Graeme Rocher [ 17/Jun/11 ]

Peter mentioned you can't use the Gradle integration to build a Groovy project, is this the case? Seems a bit of a limitation that

Comment by Andy Clement [ 17/Jun/11 ]

> I update the the latest snapshot, but now I have hundreds of compilation errors. With lots of "BuildSettings cannot be resolved as a type"

hmmm, works for me. I just git pulled to make sure I had the latest and it was OK. Did you do anything special like import the grails codebase using the gradle integration? Or did you just import as existing projects? From your other question I wonder if you used the gradle integration, I haven't tried that route.

> Peter mentioned you can't use the Gradle integration to build a Groovy project, is this the case? Seems a bit of a limitation that

Basically the API we use from gradle is very bare bones, they haven't fleshed it out yet - we don't know if the thing you are importing is a groovy project, aspectj project, or whatever. if you have run gradle eclipse and created the .project/.classpath files then it will import and build OK because the gradle integration will not damage/interfere with existing metadata, it will just start managing the classpath for you based on your gradle declared dependencies.

It does seem a limitation, yes, but no-one is shouting up and down asking for it. It appears supporting web projects is more important right now.

But, as I say, it is something where we have to ask the gradle team to enhance their IDE API, it isn't something we can solve by ourselves.





[GRECLIPSE-1086] When using the Groovy Eclipse Compiler within a Maven build, setting maven-compiler-plugin option forked = true causes "invalid flag: -jar" error Created: 15/Jun/11  Updated: 20/Jun/11  Resolved: 20/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: None
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Knute Axelson Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using the following settings for maven-compiler-plugin:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<!-- <fork>true</fork> -->
<compilerVersion>1.5</compilerVersion>
<encoding>ISO-8859-1</encoding>
<source>1.5</source>
<target>1.5</target>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.5.1-M3</version>
</dependency>
</dependencies>
</plugin>

I receive the following error:

[INFO] Compiling in a forked process using C:\Users\kaxelson\.m2\repository\org\codehaus\groovy\groovy-eclipse-batch\1.8.0-03\groovy-eclipse-batch-1.8.0-03.jar
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Failure executing groovy-eclipse compiler:
javac: invalid flag: -jar
Usage: javac <options> <source files>
use -help for a list of possible options

[INFO] 1 error

Removing the <forked>true</forked> from the plugin config resolves the problem.



 Comments   
Comment by Knute Axelson [ 15/Jun/11 ]

I have a slight error in my description. The <forked>true</forked> line should not be commented out in the pom snippet.

Comment by Andrew Eisenberg [ 20/Jun/11 ]

Are you by any chance explicitly specifying 'javac' as an executable somewhere in your pom? The only way that I can reproduce your problem is by using a configuration like this:

<configuration>
  <compilerId>groovy-eclipse-compiler</compilerId>
  <executable>javac</executable>
  <fork>true</fork>
</configuration>

When I remove the javac option, then things work fine.

This is a small bug in the groovy-eclipse-compiler since we should never be looking at the executable option (and I'll fix this), but the workaround is easy.

Comment by Andrew Eisenberg [ 20/Jun/11 ]

Now fixed locally. Please re-open if this is not the problem that you were having.





[parser] Better parser recovery (GRECLIPSE-468)

[GRECLIPSE-1085] Parser throws exception when dealing with malformed label statements Created: 14/Jun/11  Updated: 01/Nov/11  Resolved: 01/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: 2.5.0Release
Fix Version/s: 2.6.0.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There are a few variants of bad syntax that causes the parser to throw an exception:

foo:"fdasfdsa",
foo:

Stack trace snippet:

...
Caused by: java.lang.NullPointerException
	at org.codehaus.groovy.antlr.AntlrParserPlugin.statement(AntlrParserPlugin.java:1435)
	at org.codehaus.groovy.antlr.AntlrParserPlugin.labelledStatement(AntlrParserPlugin.java:1647)
	at org.codehaus.groovy.antlr.AntlrParserPlugin.statement(AntlrParserPlugin.java:1452)
	at org.codehaus.groovy.antlr.AntlrParserPlugin.convertGroovy(AntlrParserPlugin.java:377)
	at org.codehaus.groovy.antlr.AntlrParserPlugin.buildAST(AntlrParserPlugin.java:267)
	at org.codehaus.groovy.control.SourceUnit.convert(SourceUnit.java:298)
	at org.codehaus.groovy.control.CompilationUnit$3.call(CompilationUnit.java:677)
...

I came across this because I was typing out a method call that used named arguments, and I pressed enter while there was a missing comma.



 Comments   
Comment by Andy Clement [ 31/Oct/11 ]

can't get this to fail, I've tried a few variants but unable to create the exception. I need a more complete bit of test code to progress with this.

Comment by Andrew Eisenberg [ 31/Oct/11 ]

I can't get the exception either, but there is still a parser recovery problem. The parser can not create the structure when there are broken label statements like above.

Comment by Andy Clement [ 01/Nov/11 ]

all fixed up (on 1.8)





[GRECLIPSE-1083] When using the Groovy Eclipse Compiler within a Maven build, it does not compile any source files if all the source files are .java Created: 14/Jun/11  Updated: 15/Jun/11  Resolved: 15/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration
Affects Version/s: None
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Knute Axelson Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Maven reports the following:

[INFO] — maven-compiler-plugin:2.3.1:compile (default-compile) @ asset-cpms-tags —
[INFO] Nothing to compile - all classes are up to date

This is for a project that contains 22 .java source files and 0 .groovy source files



 Comments   
Comment by Andrew Eisenberg [ 14/Jun/11 ]

Can you attach your pom, or at least the relevant snippets of with the reference to groovy-eclipse-compiler?

Comment by Knute Axelson [ 15/Jun/11 ]

Here's a snippet from my pom:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<executable>$

{maven.compiler.executable}

</executable>
<fork>true</fork>
<compilerVersion>1.5</compilerVersion>
<encoding>ISO-8859-1</encoding>
<source>1.5</source>
<target>1.5</target>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.5.1</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>1.8.0-03</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/main/groovy</source>
<source>src/main/java</source>
</sources>
</configuration>
</execution>
<execution>
<id>add-test-source</id>
<phase>generate-test-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<source>src/test/groovy</source>
<source>src/test/java</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<additionalProjectnatures>
<projectnature>org.eclipse.jdt.groovy.core.groovyNature</projectnature>
</additionalProjectnatures>
</configuration>
</plugin>

If I add a groovy file under src/main/groovy such as Dummy.groovy with the following contents:

class Dummy {}

If I add this, everything compiles fine - both Java and Groovy files.

Comment by Knute Axelson [ 15/Jun/11 ]

Another note:

If I change the pom as follows:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<executable>$

{maven.compiler.executable}

</executable>
<fork>true</fork>
<compilerVersion>1.5</compilerVersion>
<encoding>ISO-8859-1</encoding>
<source>1.5</source>
<target>1.5</target>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.5.1-M3</version>
</dependency>
</dependencies>
</plugin>

I get this error:

[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Failure executing groovy-eclipse compiler:
javac: invalid flag: -jar

Comment by Andrew Eisenberg [ 15/Jun/11 ]

The original problem reported in this issue was related to a previous snapshot of the groovy-eclipse-compiler, but it has since been fixed when using 2.5.1.M3. I see that you are already using this. I also see that you have opened bug GRECLIPSE-1086. I am closing this issue as fixed, but please re-open if you are still having a problem.

Comment by Andrew Eisenberg [ 15/Jun/11 ]

Fixed.





[GRECLIPSE-1082] DSLD container deadlocking STS during startup Created: 13/Jun/11  Updated: 13/Jun/11  Resolved: 13/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: None
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File stuck-sts.txt    
Number of attachments : 1

 Description   

I got a complete freezeup when opeing STS on my development workspace. (Actually it happened after I 'switch workspace'
from simple testing workspace, to the my dev workspace that has most of STS, Greclipse and a lot of other stuff in it).

I'm not sure how rare this is, or how to trigger it, but with this workspace, I seem to get it every time
I start STS.



 Comments   
Comment by Kris De Volder [ 13/Jun/11 ]

Closing.... seems Andrew fixed it.





[GRECLIPSE-1081] Operator overloading should be configurable through DSLDs Created: 12/Jun/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support, Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.6.1.Release

Type: Task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by GRECLIPSE-1290 Inferring the type of overloaded bina... Resolved
Number of attachments : 0

 Description   

If a user chooses to add a DSLD contribution for a method that corresponds to an operator (such as add, getAt, etc), references to the operator should be handled through the inferencing engine.

For example, when this DSLD is used:

currentType ("Foo").accept {
  method name:"getAt", type:"Other"
}

x in this code should be of type Other:

def x = new Foo()[0]

This feature is most important for the getAt method, since most other operators will return instances of the same type of the target instance, but we should consider implementing for more than just getAt.



 Comments   
Comment by Andrew Eisenberg [ 15/Dec/11 ]

I have a prototype implementation that I think will work. Need to test it before committing.

Comment by Andrew Eisenberg [ 17/Dec/11 ]

This issue is now fixed along with GRECLIPSE-1290.





[GRECLIPSE-1080] Create a way to disable DSL support Created: 12/Jun/11  Updated: 13/Jun/11  Resolved: 13/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support, Project Settings
Affects Version/s: None
Fix Version/s: 2.5.1Release

Type: Task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Although, we are hoping that DSLD support in Groovy-Eclipse will not take up too much CPU or memory, there should be a way of disabling it completely. Perhaps there could be a checkbox in the preferences page to control it.



 Comments   
Comment by Andrew Eisenberg [ 13/Jun/11 ]

Now available in latest dev build





[GRECLIPSE-1079] Methods defined in java.lang.Class are underlined for Groovy classes Created: 08/Jun/11  Updated: 09/Jun/11  Resolved: 09/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.1Release

Type: Improvement Priority: Minor
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Example:

package foo

class Foo {

	public static void main(String[] args) {
		println Foo.getName()
	}
	
}

The method 'getName' will be underlined... but it calls the java.lang.Class.getName method so it shouldn't be underlined.

It should also appear in content assist after Foo.<CTRL-SPACE>.



 Comments   
Comment by Andrew Eisenberg [ 09/Jun/11 ]

Currently, in order to access the methods and properties on Class, you need explicitly add the reference to class, like this:

println Foo.class.name

This is obviously wrong.

Comment by Andrew Eisenberg [ 09/Jun/11 ]

A fix for this can also help make GRECLIPSE-855 work.

Comment by Andrew Eisenberg [ 09/Jun/11 ]

Fixed with regression tests.





[GRECLIPSE-1078] DSLD container refresh logging lots of errors Created: 08/Jun/11  Updated: 10/Jun/11  Resolved: 10/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I see a lot of these errors in my error log:

!ENTRY org.codehaus.groovy.eclipse.dsl 4 0 2011-06-08 13:31:32.688
!MESSAGE /home/kdvolder/.groovy/greclipse/global_dsld_support does not exist
!STACK 1
Java Model Exception: Java Model Status [/home/kdvolder/.groovy/greclipse/global_dsld_support does not exist]
	at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:502)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:246)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:252)
	at org.eclipse.jdt.internal.core.Openable.open(Openable.java:432)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findDSLDsInLibraries(RefreshDSLDJob.java:102)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findFiles(RefreshDSLDJob.java:71)
	at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:216)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
!SUBENTRY 1 org.eclipse.jdt.core 4 969 2011-06-08 13:31:32.688
!MESSAGE /home/kdvolder/.groovy/greclipse/global_dsld_support does not exist

I don't think I deleted that file, so my guess is it simply wasn't created. Who's supposed to create it?



 Comments   
Comment by Andrew Eisenberg [ 09/Jun/11 ]

It is supposed to be created during DSLD refreshing if it doesn't already exist. More specifically, the classpath container should be forcing the directory to be created.

Comment by Andrew Eisenberg [ 09/Jun/11 ]

I tried this on my mac and deleted the directory. The directory was then recreated automatically. I wonder if this is a problem with being on Linux.

There is another possibility, that the directory does exist on the filesystem, but it is not being found in the Eclipse workspace's IResource abstraction of the filesystem. Can you check your filesystem to see what exists in your home directory? Do you have a .groovy folder?

Comment by Kris De Volder [ 10/Jun/11 ]

It exists on the file system. Haven't seen the error lately. Could be, as you suggest, that somehow the Eclipse and Filesystem got out of synch somehow.

Comment by Andrew Eisenberg [ 10/Jun/11 ]

So, I will close this as unreproducible, but please open if you see it again.





[GRECLIPSE-1077] DSLD container not automatically added to new or imported Grails Apps Created: 08/Jun/11  Updated: 10/Jun/11  Resolved: 09/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.5.1Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If I create a new Grails App, it doesn't look like the DSL classpath container is getting added to the project.



 Comments   
Comment by Kris De Volder [ 08/Jun/11 ]

I think at one point this did work. Not sure what broke it. But the resource listener code that detects 'new groovy projects' looks a bit fragile, assuming that the critical change it is expecting should only be changing the .project file. I suspect that for some reason the .project file change that this listener is looking for is bunched up with other changes in a single change event. The listener is only checking changes that have a single child under the project.

Comment by Kris De Volder [ 08/Jun/11 ]

I also tried importing an existing Grails project from a .zip file and seem to get the same problem.

Comment by Andrew Eisenberg [ 09/Jun/11 ]

Fixed. You're right. The thing that the resource change listener was listening to was too specific. It should have been iterating through all of the delta children regardless of how many children there are.

Comment by Andrew Eisenberg [ 09/Jun/11 ]

I am not sure if I will push this change to be available in STS 2.7.0.M2, but it will definitely be available for 2.7.0 final.

Comment by Kris De Volder [ 10/Jun/11 ]

I notice that its working. It is now breaking the Project Explorer tests in Grails, because theres an unexpected new node

GrailsExplorerTests.testProjectExplorerContentSize

Comment by Kris De Volder [ 10/Jun/11 ]

Just wondering... why not adding the container as part of the GroovyNature's configure method?

http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/IProjectNature.html#configure()

Comment by Andrew Eisenberg [ 10/Jun/11 ]

My main concern is adding the classpath container to existing/legacy projects, where the nature already exists and the configure method will not be called.

Perhaps, it makes sense to also add it during configure as well.

Comment by Andrew Eisenberg [ 10/Jun/11 ]

As for the failing test, I'll have a look to see if there is a way to make this pass easily. I have never actually gotten the UI tests running on my machine, so I can't reliably know if it is fixed until I commit the change.





[GRECLIPSE-1075] IllegalArgumentException Created: 06/Jun/11  Updated: 01/Nov/11  Resolved: 01/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.0Release
Fix Version/s: 2.6.0.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

From the mailing list (Stephen Joyner):

java.lang.IllegalArgumentException
at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java:2614)
at org.eclipse.jdt.core.dom.ASTConverter.convertImport(ASTConverter.java:2898)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1326)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:899)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:597)
at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:888)
at com.google.gdt.eclipse.platform.jdt.internal.corext.dom.ASTBatchParser.createASTs(ASTBatchParser.java:113)
at com.google.gwt.eclipse.core.validators.java.JavaCompilationParticipant.buildStarting(JavaCompilationParticipant.java:184)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.notifyParticipants(AbstractImageBuilder.java:621)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:331)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:61)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:257)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:176)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:220)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:362)
at org.eclipse.core.internal.resources.Project$1.run(Project.java:545)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:524)
at org.eclipse.core.internal.resources.Project.build(Project.java:115)
at org.eclipse.ui.actions.BuildAction.invokeOperation(BuildAction.java:222)
at org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:162)
at org.eclipse.ui.actions.WorkspaceAction$2.runInWorkspace(WorkspaceAction.java:483)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)



 Comments   
Comment by Andy Clement [ 07/Jun/11 ]

occurs when an import statement has a start position greater than 0 and a length of less than 0.

Comment by Andy Clement [ 07/Jun/11 ]

One possible way for this to occur is if the import references were created for rogue (recovery related) import nodes. However, the user ought to be seeing an error related to the import statement if that were the case. I added an assertion when the imports are being built that will trigger if we are building references that will trigger this later IAE. Doing it up front means I can at least easily include the file that is causing the issue.

Comment by Andy Clement [ 01/Nov/11 ]

If the debug triggers we can persue this further





[GRECLIPSE-1074] Opening Groovy File causes VerifyError: class: ArrayUtil, method: <clinit> signature: ()V) Illegal type in constant pool Created: 03/Jun/11  Updated: 19/Aug/11  Resolved: 19/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Robert Winch Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
      • Date: Friday, June 3, 2011 3:06:54 PM Central Daylight Time
      • Platform Details:
      • System properties:
        com.atlassian.connector.eclipse.branding.ui.isOnlyJiraInstalled=true
        eclipse.application=org.eclipse.ui.ide.workbench
        eclipse.buildId=2.6.1.201105041000-RELEASE
        eclipse.commands=-os
        linux
        -ws
        gtk
        -arch
        x86
        -showsplash
        -launcher
        /home/rwinch/downloads/springsource/sts-2.6.0.SR1/STS
        -name
        STS
        --launcher.library
        /home/rwinch/downloads/springsource/sts-2.6.0.SR1//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.1.2.R36x_v20101019_1345/eclipse_1310.so
        -startup
        /home/rwinch/downloads/springsource/sts-2.6.0.SR1//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
        -product
        com.springsource.sts.ide
        -vm
        /usr/lib/jvm/jdk1.6.0_24/jre/bin/../lib/i386/client/libjvm.so
        eclipse.home.location=file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/
        eclipse.launcher=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/STS
        eclipse.launcher.name=STS
        eclipse.p2.data.area=@config.dir/../p2/
        eclipse.p2.profile=com.springsource.sts.ide
        eclipse.product=com.springsource.sts.ide
        eclipse.startTime=1307107267021
        eclipse.vm=/usr/lib/jvm/jdk1.6.0_24/jre/bin/../lib/i386/client/libjvm.so
        eclipse.vmargs=-Dosgi.requiredJavaVersion=1.5
        -Xms40m
        -Xmx768m
        -XX:MaxPermSize=256m
        -Djava.class.path=/home/rwinch/downloads/springsource/sts-2.6.0.SR1//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
        equinox.use.ds=true
        file.encoding=UTF-8
        file.encoding.pkg=sun.io
        file.separator=/
        guice.disable.misplaced.annotation.check=true
        java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
        java.awt.printerjob=sun.print.PSPrinterJob
        java.class.path=/home/rwinch/downloads/springsource/sts-2.6.0.SR1//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
        java.class.version=50.0
        java.endorsed.dirs=/usr/lib/jvm/jdk1.6.0_24/jre/lib/endorsed
        java.ext.dirs=/usr/lib/jvm/jdk1.6.0_24/jre/lib/ext:/usr/java/packages/lib/ext
        java.home=/usr/lib/jvm/jdk1.6.0_24/jre
        java.io.tmpdir=/tmp
        java.library.path=/usr/lib/jvm/jdk1.6.0_24/jre/lib/i386/client:/usr/lib/jvm/jdk1.6.0_24/jre/lib/i386::/usr/java/packages/lib/i386:/lib:/usr/lib
        java.protocol.handler.pkgs=org.apache.axis.transport|
        java.runtime.name=Java(TM) SE Runtime Environment
        java.runtime.version=1.6.0_24-b07
        java.specification.name=Java Platform API Specification
        java.specification.vendor=Sun Microsystems Inc.
        java.specification.version=1.6
        java.vendor=Sun Microsystems Inc.
        java.vendor.url=http://java.sun.com/
        java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi
        java.version=1.6.0_24
        java.vm.info=mixed mode, sharing
        java.vm.name=Java HotSpot(TM) Client VM
        java.vm.specification.name=Java Virtual Machine Specification
        java.vm.specification.vendor=Sun Microsystems Inc.
        java.vm.specification.version=1.0
        java.vm.vendor=Sun Microsystems Inc.
        java.vm.version=19.1-b02
        line.separator=

org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
org.eclipse.debug.ui.breakpoints.toggleFactoriesUsed=false
org.eclipse.equinox.launcher.splash.location=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/com.springsource.sts_2.6.1.201105041000-RELEASE/splash.bmp
org.eclipse.equinox.simpleconfigurator.configUrl=file:org.eclipse.equinox.simpleconfigurator/bundles.info
org.eclipse.jdt.debug.ui.debuggerActive=false
org.eclipse.jdt.debug.ui.instanceof.IJavaStackFrame=false
org.eclipse.jdt.debug.ui.supportsForceReturn=false
org.eclipse.jdt.debug.ui.supportsInstanceRetrieval=false
org.eclipse.update.reconcile=false
org.osgi.framework.executionenvironment=OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,JRE-1.1,J2SE-1.2,J2SE-1.3,J2SE-1.4,J2SE-1.5,JavaSE-1.6
org.osgi.framework.language=en
org.osgi.framework.os.name=Linux
org.osgi.framework.os.version=2.6.38
org.osgi.framework.processor=x86
org.osgi.framework.system.packages=javax.accessibility,javax.activation,javax.activity,javax.annotation,javax.annotation.processing,javax.crypto,javax.crypto.interfaces,javax.crypto.spec,javax.imageio,javax.imageio.event,javax.imageio.metadata,javax.imageio.plugins.bmp,javax.imageio.plugins.jpeg,javax.imageio.spi,javax.imageio.stream,javax.jws,javax.jws.soap,javax.lang.model,javax.lang.model.element,javax.lang.model.type,javax.lang.model.util,javax.management,javax.management.loading,javax.management.modelmbean,javax.management.monitor,javax.management.openmbean,javax.management.relation,javax.management.remote,javax.management.remote.rmi,javax.management.timer,javax.naming,javax.naming.directory,javax.naming.event,javax.naming.ldap,javax.naming.spi,javax.net,javax.net.ssl,javax.print,javax.print.attribute,javax.print.attribute.standard,javax.print.event,javax.rmi,javax.rmi.CORBA,javax.rmi.ssl,javax.script,javax.security.auth,javax.security.auth.callback,javax.security.auth.kerberos,javax.security.auth.login,javax.security.auth.spi,javax.security.auth.x500,javax.security.cert,javax.security.sasl,javax.sound.midi,javax.sound.midi.spi,javax.sound.sampled,javax.sound.sampled.spi,javax.sql,javax.sql.rowset,javax.sql.rowset.serial,javax.sql.rowset.spi,javax.swing,javax.swing.border,javax.swing.colorchooser,javax.swing.event,javax.swing.filechooser,javax.swing.plaf,javax.swing.plaf.basic,javax.swing.plaf.metal,javax.swing.plaf.multi,javax.swing.plaf.synth,javax.swing.table,javax.swing.text,javax.swing.text.html,javax.swing.text.html.parser,javax.swing.text.rtf,javax.swing.tree,javax.swing.undo,javax.tools,javax.transaction,javax.transaction.xa,javax.xml,javax.xml.bind,javax.xml.bind.annotation,javax.xml.bind.annotation.adapters,javax.xml.bind.attachment,javax.xml.bind.helpers,javax.xml.bind.util,javax.xml.crypto,javax.xml.crypto.dom,javax.xml.crypto.dsig,javax.xml.crypto.dsig.dom,javax.xml.crypto.dsig.keyinfo,javax.xml.crypto.dsig.spec,javax.xml.datatype,javax.xml.namespace,javax.xml.parsers,javax.xml.soap,javax.xml.stream,javax.xml.stream.events,javax.xml.stream.util,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.sax,javax.xml.transform.stax,javax.xml.transform.stream,javax.xml.validation,javax.xml.ws,javax.xml.ws.handler,javax.xml.ws.handler.soap,javax.xml.ws.http,javax.xml.ws.soap,javax.xml.ws.spi,javax.xml.ws.wsaddressing,javax.xml.xpath,org.ietf.jgss,org.omg.CORBA,org.omg.CORBA_2_3,org.omg.CORBA_2_3.portable,org.omg.CORBA.DynAnyPackage,org.omg.CORBA.ORBPackage,org.omg.CORBA.portable,org.omg.CORBA.TypeCodePackage,org.omg.CosNaming,org.omg.CosNaming.NamingContextExtPackage,org.omg.CosNaming.NamingContextPackage,org.omg.Dynamic,org.omg.DynamicAny,org.omg.DynamicAny.DynAnyFactoryPackage,org.omg.DynamicAny.DynAnyPackage,org.omg.IOP,org.omg.IOP.CodecFactoryPackage,org.omg.IOP.CodecPackage,org.omg.Messaging,org.omg.PortableInterceptor,org.omg.PortableInterceptor.ORBInitInfoPackage,org.omg.PortableServer,org.omg.PortableServer.CurrentPackage,org.omg.PortableServer.POAManagerPackage,org.omg.PortableServer.POAPackage,org.omg.PortableServer.portable,org.omg.PortableServer.ServantLocatorPackage,org.omg.SendingContext,org.omg.stub.java.rmi,org.w3c.dom,org.w3c.dom.bootstrap,org.w3c.dom.css,org.w3c.dom.events,org.w3c.dom.html,org.w3c.dom.ls,org.w3c.dom.ranges,org.w3c.dom.stylesheets,org.w3c.dom.traversal,org.w3c.dom.views,org.w3c.dom.xpath,org.xml.sax,org.xml.sax.ext,org.xml.sax.helpers
org.osgi.framework.vendor=Eclipse
org.osgi.framework.version=1.5.0
org.osgi.supports.framework.extension=true
org.osgi.supports.framework.fragment=true
org.osgi.supports.framework.requirebundle=true
os.arch=i386
os.name=Linux
os.version=2.6.38-8-generic-pae
osgi.arch=x86
osgi.bundles=reference:file:javax.transaction_1.1.1.v201006150915.jar,reference:file:org.eclipse.equinox.weaving.hook_1.0.0.v20100108.jar,reference:file:org.eclipse.persistence.jpa.equinox.weaving_2.1.2.v20101206-r8635.jar,reference:file:org.eclipse.equinox.simpleconfigurator_1.0.200.v20100503.jar@1:start
osgi.bundles.defaultStartLevel=4
osgi.bundlestore=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/configuration/org.eclipse.osgi/bundles
osgi.configuration.area=file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/configuration/
osgi.framework=file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/org.eclipse.osgi_3.6.2.R36x_v20110210.jar
osgi.framework.extensions=reference:file:javax.transaction_1.1.1.v201006150915.jar,reference:file:org.eclipse.equinox.weaving.hook_1.0.0.v20100108.jar,reference:file:org.eclipse.persistence.jpa.equinox.weaving_2.1.2.v20101206-r8635.jar
osgi.framework.shape=jar
osgi.framework.version=3.6.2.R36x_v20110210
osgi.frameworkClassPath=., file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/javax.transaction_1.1.1.v201006150915.jar, file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/org.eclipse.equinox.weaving.hook_1.0.0.v20100108.jar, file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/org.eclipse.persistence.jpa.equinox.weaving_2.1.2.v20101206-r8635.jar
osgi.install.area=file:/home/rwinch/downloads/springsource/sts-2.6.0.SR1/
osgi.instance.area=file:/home/rwinch/Documents/workspace-sts-2.6.0.RELEASE/
osgi.instance.area.default=file:/home/rwinch/Documents/workspace-sts-2.6.1.RELEASE/
osgi.logfile=/home/rwinch/Documents/workspace-sts-2.6.0.RELEASE/.metadata/.log
osgi.manifest.cache=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/configuration/org.eclipse.osgi/manifests
osgi.nl=en_US
osgi.os=linux
osgi.requiredJavaVersion=1.5
osgi.splashLocation=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins/com.springsource.sts_2.6.1.201105041000-RELEASE/splash.bmp
osgi.splashPath=platform:/base/plugins/com.springsource.sts
osgi.syspath=/home/rwinch/downloads/springsource/sts-2.6.0.SR1/plugins
osgi.tracefile=/home/rwinch/Documents/workspace-sts-2.6.0.RELEASE/.metadata/trace.log
osgi.user.area=file:/home/rwinch/user/
osgi.ws=gtk
path.separator=:
securerandom.source=file:/dev/./urandom
sun.arch.data.model=32
sun.boot.class.path=/usr/lib/jvm/jdk1.6.0_24/jre/lib/resources.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/rt.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/sunrsasign.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/jsse.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/jce.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/charsets.jar:/usr/lib/jvm/jdk1.6.0_24/jre/lib/modules/jdk.boot.jar:/usr/lib/jvm/jdk1.6.0_24/jre/classes
sun.boot.library.path=/usr/lib/jvm/jdk1.6.0_24/jre/lib/i386
sun.cpu.endian=little
sun.cpu.isalist=
sun.desktop=gnome
sun.io.unicode.encoding=UnicodeLittle
sun.jnu.encoding=UTF-8
sun.management.compiler=HotSpot Client Compiler
sun.os.patch.level=unknown
user.country=US
user.dir=/home/rwinch
user.home=/home/rwinch
user.language=en
user.name=rwinch
user.timezone=America/Chicago

      • Features:
        com.atlassian.connector.eclipse.jira (2.3.0.v20100901) "Atlassian Connector for Eclipse Branding"
        com.springsource.sts (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.maven (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.package (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.patch (2.6.0.201104111100-PATCH) "SpringSource Tool Suite"
        com.springsource.sts.roo (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.server.tc (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.tutorials (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite"
        com.springsource.sts.vmware (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite"
        com.vmware.vixapi (2.6.0.201105041000-RELEASE) "Vix API Plug-in"
        org.codehaus.groovy.eclipse.feature (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin"
        org.codehaus.groovy.jdt.patch (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin"
        org.codehaus.groovy.m2eclipse (1.0.0.201102251618) "Groovy-Eclipse m2eclipse integration"
        org.codehaus.groovy17.feature (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin"
        org.codehaus.groovy18.feature (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin"
        org.eclipse.ajdt (2.1.2.e36x-20110307-1000) "AspectJ Development Tools"
        org.eclipse.cvs (1.2.1.r362_v20101111-7B77FKv99HL0GvIAF99I8H14B7E) "Eclipse CVS Client"
        org.eclipse.datatools.common.doc.user (1.8.2.v201010181125-26-311A16321A3557) "Data Tools Platform User Documentation"
        org.eclipse.datatools.connectivity.doc.user (1.8.2.v201010181125-37D-7733L3D753L7BBF) "Data Tools Platform Connectivity User Documentation"
        org.eclipse.datatools.connectivity.feature (1.8.2.v201010181125-7C7b8mEt1Zwkn9kfkUHHsoP_3to) "Data Tools Platform Connectivity Plug-in"
        org.eclipse.datatools.connectivity.oda.designer.core.feature (1.8.2.v201010181125-7B7C7ACcNBGLEOIeD_SO) "DTP ODA Designer UI Framework Plug-in"
        org.eclipse.datatools.connectivity.oda.designer.feature (1.8.2.v201010181125-4107w3121151A1A53) "DTP ODA Designer UI Framework Plug-in"
        org.eclipse.datatools.connectivity.oda.feature (1.8.2.v201010181125-7H7C7CCcNBHEDPHcETPO) "DTP Open Data Access"
        org.eclipse.datatools.doc.user (1.8.2.v201010181125-47C08w95ENAK6AFDFK7) "Data Tool Platform User Documentation"
        org.eclipse.datatools.enablement.apache.derby.feature (1.8.2.v201010181125-77778fBmKDNOMgJvJ8Of7QBR) "High-level Sybase Enablement Plug-in"
        org.eclipse.datatools.enablement.feature (1.8.2.v201010181125-7J8x7UBWwUN6z02z-fiI_w4x4uLf) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.hsqldb.feature (1.8.2.v201010181125-67C2AqGBJVKbHlH1GU7QBR) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.ibm.feature (1.8.2.v201010181125-7F47SFC7sRbrSZope9vW) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.ingres.feature (1.8.2.v201010181125-540AkF78Y7VCOCQDB) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.jdbc.feature (1.8.2.v201010181125-4-29oB56N5N7L6PAQ) "High-level Sybase Enablement Plug-in"
        org.eclipse.datatools.enablement.jdt.feature (1.8.2.v201010181125-2-07w31211518181A) "Data Tools Platform Connectivity JDT Extension Plug-in"
        org.eclipse.datatools.enablement.msft.feature (1.8.2.v201010181125-542AkF79P7QCP9SDB) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.mysql.feature (1.8.2.v201010181125-546AkF78Y7R9PAX77) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.oda.designer.feature (1.8.2.v201010181125-3328s735357795A78) "Eclipse Data Tools Platform XML ODA Designer"
        org.eclipse.datatools.enablement.oda.feature (1.8.2.v201010181125-7A7T78DZRDKDFbGwFjNK) "Eclipse Data Tools Platform XML ODA Runtime Driver"
        org.eclipse.datatools.enablement.oracle.feature (1.8.2.v201010181125-548dAkF79Q7RAN9UEE) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.postgresql.feature (1.8.2.v201010181125-542AkF77g7V9N9e77) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.sap.feature (1.8.2.v201010181125-540AkF77g7V9N9e77) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.sqlite.feature (1.8.2.v201010181125-541AkF79P7N8NAQ77) "Eclipse Data Tools Platform Enablement"
        org.eclipse.datatools.enablement.sybase.feature (1.8.2.v201010181125-7E45F9NiNZVR6a1PMVn) "High-level Sybase Enablement Plug-in"
        org.eclipse.datatools.intro (1.8.2.v201010181125-26-7w312116392911) "Eclipse Data Tools Platform Intro Plug-in"
        org.eclipse.datatools.modelbase.feature (1.8.2.v201010181125-77078CcNBGKBZI_FcRd) "Eclipse Data Tools Platform SQLModel Plug-in"
        org.eclipse.datatools.sqldevtools.ddlgen.feature (1.8.2.v201010181125-7A-3F7RZHLz-Hz-OlPz0Qf) "Eclipse Data Tools Platform FE UI Plug-in"
        org.eclipse.datatools.sqldevtools.feature (1.8.2.v201010181125-7N7y7JFDrhqbGIFUNhcFodMMD2J0) "Eclipse Data Tools Platform SQL Tools Common UI Plug-in"
        org.eclipse.datatools.sqldevtools.parsers.feature (1.8.2.v201010181125-622BgJ9CR9XFcEWLP) "Eclipse Data Tools Platform SQL Parser Plugin"
        org.eclipse.datatools.sqltools.doc.user (1.8.2.v201010181125-37D-7733L3D753L7BBF) "Data Tools Platform SQL Tools User Documentation"
        org.eclipse.draw2d (3.6.2.v20110128-0100-4517w3122123901211) "Graphical Editing Framework Draw2d"
        org.eclipse.egit (0.12.1) "Git Team Provider (Incubation)"
        org.eclipse.emf (2.6.1.v20100914-1218) "EMF - Eclipse Modeling Framework Runtime and Tools"
        org.eclipse.emf.codegen (2.6.0.v20100914-1218) "EMF Code Generation"
        org.eclipse.emf.codegen.ecore (2.6.1.v20100914-1218) "EMF Ecore Code Generator"
        org.eclipse.emf.codegen.ecore.ui (2.6.0.v20100914-1218) "EMF Ecore Code Generator UI"
        org.eclipse.emf.codegen.ui (2.6.0.v20100914-1218) "EMF Code Generation UI"
        org.eclipse.emf.common (2.6.0.v20100914-1218) "EMF Common"
        org.eclipse.emf.common.ui (2.6.0.v20100914-1218) "EMF Common UI"
        org.eclipse.emf.converter (2.6.0.v20100914-1218) "EMF Model Converter"
        org.eclipse.emf.databinding (1.2.0.v20100914-1218) "EMF Data Binding"
        org.eclipse.emf.databinding.edit (1.2.0.v20100914-1218) "EMF Edit Data Binding"
        org.eclipse.emf.ecore (2.6.1.v20100914-1218) "EMF Ecore"
        org.eclipse.emf.ecore.edit (2.6.0.v20100914-1218) "EMF Ecore Edit"
        org.eclipse.emf.ecore.editor (2.6.0.v20100914-1218) "EMF Sample Ecore Editor"
        org.eclipse.emf.edit (2.6.0.v20100914-1218) "EMF Edit"
        org.eclipse.emf.edit.ui (2.6.0.v20100914-1218) "EMF Edit UI"
        org.eclipse.emf.mapping (2.6.0.v20100914-1218) "EMF Mapping"
        org.eclipse.emf.mapping.ecore (2.6.0.v20100914-1218) "EMF Ecore Mapping"
        org.eclipse.emf.mapping.ecore.editor (2.6.0.v20100914-1218) "EMF Ecore Mapping Editor"
        org.eclipse.emf.mapping.ui (2.6.0.v20100914-1218) "EMF Mapping UI"
        org.eclipse.gef (3.6.2.v20110128-0100-777B381A4Bz06565376E32322) "Graphical Editing Framework GEF"
        org.eclipse.help (1.2.1.r362_v20101111-7e7jEVFDr6xg-LSlC_z0w1D) "Help System Base"
        org.eclipse.jdt (3.6.2.r362_v20101117-0800-7z8XFW6FLFlmjJcvz03jyeFBLS_F) "Eclipse Java Development Tools"
        org.eclipse.jgit (0.12.1) "JGit Core (Incubation)"
        org.eclipse.jpt.eclipselink.feature (2.3.3.v201102072310-7778BkBgJ9EA9VGcDFBA) "Dali Java Persistence Tools - EclipseLink Support"
        org.eclipse.jpt.feature (2.3.3.v201010220000-7N7UF77FD3wTgcVbmmf0cT) "Dali Java Persistence Tools"
        org.eclipse.jst.common.fproj.enablement.jdt (3.2.2.v201008170019-377AB8s73533J5J759F) "Eclipse Faceted Project Framework JDT Enablement"
        org.eclipse.jst.enterprise_ui.feature (3.2.3.v201011031800-7b7GHfIFSK2WBRT6E1mcyFXGPnSh) "Eclipse Java EE Developer Tools"
        org.eclipse.jst.ws.axis2tools.feature (1.1.100.v201005241530-78-FF0DZRDKDDePSKwHj) "Axis2 Tools"
        org.eclipse.mylyn_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.bugzilla_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.context_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.ide_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.java_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.jira_feature (3.4.0) "Atlassian Connector for Eclipse Branding"
        org.eclipse.mylyn.team_feature (3.5.0.v20110316-0100) "Mylyn"
        org.eclipse.mylyn.wikitext_feature (1.4.0.v20110316-0100) "Mylyn"
        org.eclipse.pde (3.6.2.r362_v20110203-7b7mFL2FET3dhHalh1iNZtL) "PDE"
        org.eclipse.persistence.jpa (2.1.2.v20101206-r8635) "EclipseLink JPA"
        org.eclipse.persistence.moxy (2.1.2.v20101206-r8635) "EclipseLink MOXy"
        org.eclipse.persistence.sdo (2.1.2.v20101206-r8635) "EclipseLink SDO"
        org.eclipse.platform (3.6.2.r362_v20110210-9gF78Gs1FrIGnHDHWkEcopoN8AmxeZflGDGKQi) "Eclipse Platform"
        org.eclipse.rcp (3.6.2.r362_v20101104-9SAxFMKFkSAqi8axkv1ZjegmiBLY) "Eclipse RCP"
        org.eclipse.rse (3.2.2.R32x_v201102130925-7L78FA58SreKCHr_JG7UA8bra19p) "Remote System Explorer End-User Runtime"
        org.eclipse.rse.core (3.2.2.R32x_v201102011435-7a7FFMcF9hxfDPvGY6d8rTEETOY) "RSE Core"
        org.eclipse.rse.dstore (3.2.2.R32x_v201102011435-7L77FDBD2YO5DwmNgNdOG98LBL) "RSE DStore Services"
        org.eclipse.rse.ftp (3.0.200.v201005221100-780Bg9oB56N5J9QBADD) "RSE FTP Service"
        org.eclipse.rse.local (2.1.202.R32x_v201102011435-7B4F8QBCKC5H2XIVHMB922546) "RSE Local Services"
        org.eclipse.rse.ssh (3.0.100.v201005221100-7A2BhAkF77g7VEYDG7C) "RSE SSH Services"
        org.eclipse.rse.telnet (2.2.100.v201005221100-7730AkF77g7UDXELEF) "RSE Telnet Service"
        org.eclipse.rse.terminals (1.0.102.R32x_v201102011435-77-DI9uCFjNZVBGlDNC332423365) "RSE Terminals UI"
        org.eclipse.rse.useractions (1.1.200.v201005221100-31A78s733L3D7H7933) "Remote System Explorer User Actions"
        org.eclipse.team.svn (0.7.9.I20110523-1700) "Subversive SVN Team Provider (Incubation)"
        org.eclipse.team.svn.mylyn (0.7.9.I20110523-1700) "Subversive Integration for the Mylyn Project (Incubation)"
        org.eclipse.team.svn.resource.ignore.rules.jdt (0.7.9.I20110523-1700) "Subversive JDT Ignore Extensions (Incubation)"
        org.eclipse.tm.terminal (3.0.202.R32x_v201102011435-4-8a7S43yaw312213122546) "Target Management Terminal Widget"
        org.eclipse.tm.terminal.ssh (2.0.200.v201005271030-3-A77w312116382141) "Target Management Terminal SSH Connector"
        org.eclipse.tm.terminal.telnet (2.0.200.v201005032000-3-8_7w311A1A271116) "Target Management Terminal Telnet Connector"
        org.eclipse.tm.terminal.view (2.1.2.R32x_v201102011435-3017S43yaw312213122546) "Target Management Terminal View"
        org.eclipse.wst.common.fproj (3.2.3.v201101121727-377AC8s73543C6H4A5H) "Eclipse Faceted Project Framework"
        org.eclipse.wst.jsdt.feature (1.2.3.v201102160540-7C78FGUF9JgLWNO2UCNqfa) "Eclipse JavaScript Development Tools"
        org.eclipse.wst.web_ui.feature (3.2.3.v201102160541-7O7CFbWEMf84qYjGDyP3DNEwcgFU) "Eclipse Web Developer Tools"
        org.eclipse.wst.xml_ui.feature (3.2.3.v201102160550-7H7AFUWDxumQJOi9ghcTb5YgkwEZ) "Eclipse XML Editors and Tools"
        org.eclipse.wst.xml.xpath2.processor.feature (1.1.6.v201101212357-67K3BgJ9DJAPEUCSKQ) "Eclipse XPath 2 Developers Tools"
        org.eclipse.wst.xsl.feature (1.1.3.v201102102045-7S7WFASFIpS-21NUD58xfPVDTLR) "Eclipse XSL Developer Tools"
        org.eclipse.zest (1.2.0.v20100519-2050-67818yE6F-AA7P4B8I52322) "Graphical Editing Framework Zest Core"
        org.maven.ide.eclipse.ajdt.feature (0.10.0.20100209-0800) "Maven Integration for Eclipse"
        org.maven.ide.eclipse.feature (0.12.1.20110112-1712) "Maven Integration for Eclipse"
        org.maven.ide.eclipse.temporary.mojos.feature (0.12.0.20101103-1500) "Maven Integration for Eclipse"
        org.maven.ide.eclipse.wtp.feature (0.11.1.20101108-1810) "Maven Integration for Eclipse"
        org.polarion.eclipse.team.svn.connector (2.2.2.I20110523-1700) "Subversive SVN Connectors"
        org.polarion.eclipse.team.svn.connector.javahl16 (2.2.2.I20110523-1700) "Subversive SVN 1.6 JavaHL Connector"
        org.polarion.eclipse.team.svn.connector.svnkit16 (2.2.2.I20110523-1700) "Subversive SVN 1.6 SVN Kit Connector"
        org.springframework.ide.eclipse.ajdt.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.aop.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.autowire.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.batch.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.integration.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.mylyn.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.osgi.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.security.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.springframework.ide.eclipse.webflow.feature (2.6.0.201103160035-RELEASE) "Spring IDE"
        org.zeroturnaround.eclipse.feature (1.4.1.201106011212) "JRebel Eclipse Plug-in"
        org.zeroturnaround.eclipse.wtp.feature (1.4.0.201105311642) "JRebel WTP Integration Plug-in"
      • Plug-in Registry:
        com.atlassian.connector.eclipse.branding.ui (2.3.0.v20100901) "Atlassian Connector for Eclipse Branding" [Active]
        com.atlassian.connector.eclipse.commons.core (2.3.0.v20100901) "Atlassian Connector for Eclipse Commons Core" [Active]
        com.atlassian.connector.eclipse.commons.ui (2.3.0.v20100901) "Atlassian Connector for Eclipse UI Commons" [Active]
        com.atlassian.connector.eclipse.jira.core (2.3.0.v20100901) "Atlassian Connector for Eclipse Jira Core" [Active]
        com.atlassian.connector.eclipse.jira.ui (2.3.0.v20100901) "Atlassian Connector for Eclipse JIRA UI" [Active]
        com.caucho.hessian (3.2.0) "Caucho Hessian Plug-in" [Resolved]
        com.ibm.icu (4.2.1.v20100412) "International Components for Unicode for Java (ICU4J)" [Active]
        com.jcraft.jsch (0.1.41.v200903070017) "JSch" [Resolved]
        com.lowagie.text (2.1.7.v201004222200) "Lowagie iText" [Resolved]
        com.springsource.javax.el (1.0.0) "Java Expression Language API" [Resolved]
        com.springsource.javax.jms (1.1.0) "Java Messaging System API" [Resolved]
        com.springsource.javax.servlet (2.5.0) "Java Servlet API" [Resolved]
        com.springsource.javax.servlet.jsp (2.1.0) "Java JSP API" [Resolved]
        com.springsource.javax.servlet.jsp.jstl (1.2.0) "Java JSP Standard Tag Library" [Resolved]
        com.springsource.org.antlr (3.0.1) "ANTLR" [Resolved]
        com.springsource.org.apache.myfaces.javax.faces (1.2.2) "Apache MyFaces JSF API" [Resolved]
        com.springsource.org.aspectj.weaver (1.6.10.RELEASE) "AspectJ Weaver" [Resolved]
        com.springsource.org.objectweb.asm (2.2.3) "ObjectWeb ASM" [Resolved]
        com.springsource.org.objectweb.asm.commons (2.2.3) "ObjectWeb ASM Commons" [Resolved]
        com.springsource.sts (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite" [Active]
        com.springsource.sts.bestpractices (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Best Practices" [Starting]
        com.springsource.sts.config.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Spring Configuration Editor (Core)" [Active]
        com.springsource.sts.config.flow (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Configuration Flow Editing" [Active]
        com.springsource.sts.config.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Spring Configuration Editor (UI)" [Active]
        com.springsource.sts.content.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Content (Core)" [Active]
        com.springsource.sts.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite (Core)" [Active]
        com.springsource.sts.frameworks.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Framework Support Core" [Active]
        com.springsource.sts.frameworks.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Framework Support (UI)" [Active]
        com.springsource.sts.ide.configurator (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Workspace Configuration" [Active]
        com.springsource.sts.ide.help (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Help and Support" [Active]
        com.springsource.sts.ide.metadata (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Spring Meta Data Extension" [Active]
        com.springsource.sts.ide.osgi (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite OSGi Runtime Support" [Active]
        com.springsource.sts.ide.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite (UI)" [Active]
        com.springsource.sts.maven (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Maven Integration" [Active]
        com.springsource.sts.quickfix (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Quick Fixes" [Active]
        com.springsource.sts.roo.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Roo Integration (Core)" [Active]
        com.springsource.sts.roo.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite Roo Integration (UI)" [Active]
        com.springsource.sts.server.commons.vmware.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite VMware Workstation Integration (Core)" [Starting]
        com.springsource.sts.server.commons.vmware.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite VMware Workstation Integration (UI)" [Starting]
        com.springsource.sts.server.insight.ui (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite tc Server Spring Insight Integration" [Active]
        com.springsource.sts.server.tc.core (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite tc Server Integration (Core)" [Resolved]
        com.springsource.sts.server.tc.reloading (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite tc Server Agent Reloading" [Starting]
        com.springsource.sts.server.tc.ui (2.6.1.201105041000-RELEASE) "SpringSource Tool Suite tc Server Integration (UI)" [Starting]
        com.springsource.sts.server.tc.vmware.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite tc Server VMware Workstation Integration (Core)" [Starting]
        com.springsource.sts.server.tc.vmware.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite tc Server VMware Workstation Integration (UI)" [Starting]
        com.springsource.sts.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite (UI)" [Active]
        com.springsource.sts.vmware.core (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite VMware Integration (Core)" [Resolved]
        com.springsource.sts.vmware.ui (2.6.0.201105041000-RELEASE) "SpringSource Tool Suite VMware Integration (UI)" [Starting]
        com.springsource.sts.wizard (2.6.0.201105041000-RELEASE) "Wizard Plug-in" [Active]
        com.springsource.util.common (2.0.0.RELEASE) "Common Utility Code" [Resolved]
        com.sun.syndication (0.9.0.v200803061811) "Rss and atOM utilitiEs (ROME)" [Resolved]
        com.vmware.vixapi (2.6.0.201105041000-RELEASE) "Vix API Plug-in" [Starting]
        commonj.sdo (2.1.1.v200905221342) "SDO API" [Starting]
        edu.emory.mathcs.backport (3.1.0.v200902251154) "JSR166 java.util.concurrency backport" [Resolved]
        java_cup.runtime (0.10.0.v201005080400) "Java Cup" [Resolved]
        javax.activation (1.1.0.v201005080500) "Apache Geronimo Activation Plug-in" [Resolved]
        javax.annotation (1.1.1.v201006150915) "geronimo jta 1.1 spec" [Resolved]
        javax.mail (1.4.0.v201005080615) "Javax Mail Plug-in" [Resolved]
        javax.persistence (2.0.1.v201006031150) "Java Persistence API 2.0" [Resolved]
        javax.servlet (2.5.0.v200910301333) "Servlet API Bundle" [Resolved]
        javax.servlet.jsp (2.0.0.v200806031607) "Java Server Pages API Bundle" [Resolved]
        javax.transaction (1.1.1.v201006150915) "geronimo annotation 1.0 spec" [Resolved]
        javax.wsdl (1.5.1.v201005080630) "WSDL4J" [Resolved]
        javax.wsdl (1.6.2.v201005080631) "WSDL4J" [Resolved]
        javax.xml (1.3.4.v201005080400) "JAXP XML" [Resolved]
        javax.xml.bind (2.2.0.v201005080402) "XML Binding for Java" [Resolved]
        javax.xml.rpc (1.1.0.v201005080400) "JAX-RPC" [Resolved]
        javax.xml.soap (1.2.0.v201005080501) "SAAJ" [Resolved]
        javax.xml.soap (1.3.0.v201005080502) "SAAJ" [Resolved]
        javax.xml.stream (1.0.1.v201004272200) "Java XML Streaming API" [Resolved]
        net.sourceforge.lpg.lpgjavaruntime (1.1.0.v201004271650) "SourceForge LPG" [Resolved]
        org.aopalliance (1.0.0.v200905130917) "Aopalliance Plug-in" [Resolved]
        org.apache.ant (1.7.1.v20100518-1145) "Apache Ant" [Resolved]
        org.apache.axis (1.4.0.v201005080400) "Apache Web Services" [Resolved]
        org.apache.bcel (5.2.0.v201005080400) "Apache BCEL" [Resolved]
        org.apache.commons.codec (1.3.0.v20100518-1140) "Apache Commons Codec Plug-in" [Resolved]
        org.apache.commons.collections (3.2.0.v201005080500) "Apache Commons Collections" [Resolved]
        org.apache.commons.discovery (0.2.0.v201004190315) "Jakarta-Commons Discovery" [Resolved]
        org.apache.commons.el (1.0.0.v201004212143) "Apache Commons JSP 2.0 Expression Language Interpreter" [Resolved]
        org.apache.commons.httpclient (3.1.0.v201005080502) "Apache Commons Httpclient" [Resolved]
        org.apache.commons.io (2.0.1.v201101200200) "pluginName" [Resolved]
        org.apache.commons.lang (2.1.0.v201005080500) "Apache Jakarta Commons Lang" [Resolved]
        org.apache.commons.lang (2.4.0.v201005080502) "Apache Jakarta Commons Lang" [Resolved]
        org.apache.commons.logging (1.0.4.v201005080501) "Apache Commons Logging Plug-in" [Resolved]
        org.apache.commons.logging (1.1.1.v201005080502) "Apache Commons Logging Plug-in" [Resolved]
        org.apache.commons.net (2.0.0.v200905272248) "Apache Commons Net" [Resolved]
        org.apache.derby (10.5.1.1_201005192117) "Apache Derby Plug-in" [Starting]
        org.apache.jasper (5.5.17.v201004212143) "Apache Jasper 2 Plug-in" [Resolved]
        org.apache.log4j (1.2.15.v201005080500) "Apache Jakarta log4j Plug-in" [Resolved]
        org.apache.lucene (1.9.1.v20100518-1140) "Apache Lucene" [Resolved]
        org.apache.lucene.analysis (1.9.1.v20100518-1140) "Apache Lucene Analysis" [Resolved]
        org.apache.oro (2.0.8.v201005080400) "Apache Jakarta ORO" [Resolved]
        org.apache.velocity (1.5.0.v200905192330) "Apache Velocity Plug-in" [Resolved]
        org.apache.ws.commons.schema (1.4.2.v201003051240) "Apache WS Commons XMLSchema Plug-in" [Resolved]
        org.apache.ws.commons.util (1.0.1.v20100518-1140) "WS Commons Util Plug-in" [Resolved]
        org.apache.wsil4j (1.0.0.v200901211807) "WSIL4J" [Resolved]
        org.apache.xalan (2.7.1.v201005080400) "Xalan-Java" [Resolved]
        org.apache.xerces (2.9.0.v201005080400) "Apache Xerces-J" [Resolved]
        org.apache.xml.resolver (1.2.0.v201005080400) "Apache XmlResolver" [Resolved]
        org.apache.xml.serializer (2.7.1.v201005080400) "Apache XML Commons Serializer" [Resolved]
        org.apache.xmlrpc (3.0.0.v20100427-1100) "Apache XML-RPC Plug-in" [Resolved]
        org.aspectj.ajde (1.6.11.20110304135300) "AspectJ" [Active]
        org.aspectj.runtime (1.6.11.20110304135300) "AspectJ Runtime" [Resolved]
        org.aspectj.weaver (1.6.11.20110304135300) "AspectJ Weaver" [Resolved]
        org.codehaus.groovy (1.7.10.xx-20110602-1000-e36) "Groovy Runtime Plug-in" [Active]
        org.codehaus.groovy (1.8.0.xx-20110602-1000-e36) "Groovy Runtime Plug-in" [Installed]
        org.codehaus.groovy.eclipse (2.5.1.xx-20110602-1000-e36) "Groovy-Eclipse plugin" [Resolved]
        org.codehaus.groovy.eclipse.ant (2.5.1.xx-20110602-1000-e36) "Groovy-Ant Plug-in" [Starting]
        org.codehaus.groovy.eclipse.astviews (2.5.1.xx-20110602-1000-e36) "Groovy AST Views" [Starting]
        org.codehaus.groovy.eclipse.codeassist.completion (2.5.1.xx-20110602-1000-e36) "Code Completion Plug-in" [Active]
        org.codehaus.groovy.eclipse.codebrowsing (2.5.1.xx-20110602-1000-e36) "Groovy Code Browsing" [Starting]
        org.codehaus.groovy.eclipse.core (2.5.1.xx-20110602-1000-e36) "Groovy Core" [Active]
        org.codehaus.groovy.eclipse.dsl (2.5.1.xx-20110602-1000-e36) "Groovy DSL support" [Active]
        org.codehaus.groovy.eclipse.quickfix (2.5.1.xx-20110602-1000-e36) "Groovy Quick Fix" [Active]
        org.codehaus.groovy.eclipse.refactoring (2.5.1.xx-20110602-1000-e36) "Groovy Refactoring Plug-in" [Active]
        org.codehaus.groovy.eclipse.ui (2.5.1.xx-20110602-1000-e36) "Groovy UI" [Active]
        org.codehaus.groovy.m2eclipse (1.0.0.201102251618) "Groovy-Eclipse m2eclipse integration" [Active]
        org.eclipse.ajdt.core (2.1.2.e36x-20110307-1000) "AspectJ Development Tools Core" [Active]
        org.eclipse.ajdt.doc.user (2.1.2.e36x-20110307-1000) "AspectJ Development Tools User Documentation" [Resolved]
        org.eclipse.ajdt.examples (2.1.2.e36x-20110307-1000) "AspectJ Examples" [Starting]
        org.eclipse.ajdt.mylyn.ui (2.1.2.e36x-20110307-1000) "Mylyn-AJDT Bridge Plug-in" [Active]
        org.eclipse.ajdt.ui (2.1.2.e36x-20110307-1000) "AspectJ Development Tools UI" [Active]
        org.eclipse.ant.core (3.2.201.v20110203_r362) "Ant Build Tool Core" [Starting]
        org.eclipse.ant.launching (1.0.1.v20101020_r362) "Ant Launching Support" [Starting]
        org.eclipse.ant.ui (3.5.0.v20100427) "Ant UI" [Active]
        org.eclipse.aspectj (2.1.2.e36x-20110307-1000) "AspectJ Development Tools" [Starting]
        org.eclipse.compare (3.5.101.R36x_v20100929-0800) "Compare Support" [Active]
        org.eclipse.compare.core (3.5.101.R36x_v20100929-0800) "Core Compare Support" [Active]
        org.eclipse.contribution.visualiser (2.2.0.e36x-20110307-1000) "Visualiser Plug-in" [Starting]
        org.eclipse.contribution.weaving.jdt (2.1.2.e36x-20110307-1000) "JDT Weaving" [Active]
        org.eclipse.contribution.xref.core (2.1.2.e36x-20110307-1000) "Cross Reference Core Plugin" [Starting]
        org.eclipse.contribution.xref.ui (2.1.2.e36x-20110307-1000) "Cross Reference UI Plugin" [Starting]
        org.eclipse.core.boot (3.1.200.v20100505) "Core Boot" [Starting]
        org.eclipse.core.commands (3.6.0.I20100512-1500) "Commands" [Resolved]
        org.eclipse.core.contenttype (3.4.100.v20100505-1235) "Eclipse Content Mechanism" [Active]
        org.eclipse.core.databinding (1.3.100.I20100601-0800) "JFace Data Binding" [Starting]
        org.eclipse.core.databinding.beans (1.2.100.I20100601-0800) "JFace Data Binding for JavaBeans" [Resolved]
        org.eclipse.core.databinding.observable (1.3.0.I20100601-0800) "JFace Data Binding Observables" [Active]
        org.eclipse.core.databinding.property (1.3.0.I20100601-0800) "JFace Data Binding" [Starting]
        org.eclipse.core.expressions (3.4.200.v20100505) "Expression Language" [Active]
        org.eclipse.core.externaltools (1.0.1.v20100831_r361) "External Tools Headless Support" [Starting]
        org.eclipse.core.filebuffers (3.5.100.v20100520-0800) "File Buffers" [Active]
        org.eclipse.core.filesystem (1.3.1.R36x_v20100727-0745) "Core File Systems" [Active]
        org.eclipse.core.filesystem.linux.x86 (1.4.0.v20100505-1235) "Core File System for Linux" [Resolved]
        org.eclipse.core.jobs (3.5.1.R36x_v20100824) "Eclipse Jobs Mechanism" [Active]
        org.eclipse.core.net (1.2.100.I20100511-0800) "Internet Connection Management" [Active]
        org.eclipse.core.net.linux.x86 (1.1.100.R36x_v20100825-0800) "Proxy for Linux" [Resolved]
        org.eclipse.core.resources (3.6.1.R36x_v20110131-1630) "Core Resource Management" [Active]
        org.eclipse.core.runtime (3.6.0.v20100505) "Core Runtime" [Active]
        org.eclipse.core.runtime.compatibility (3.2.100.v20100505) "Core Runtime Plug-in Compatibility" [Active]
        org.eclipse.core.runtime.compatibility.auth (3.2.200.v20100517) "Authorization Compatibility Plug-in" [Active]
        org.eclipse.core.runtime.compatibility.registry (3.3.0.v20100520) "Eclipse Registry Compatibility Fragment" [Resolved]
        org.eclipse.core.variables (3.2.400.v20100505) "Core Variables" [Active]
        org.eclipse.cvs (1.0.500.v201102101200) "Eclipse CVS Client" [Starting]
        org.eclipse.datatools.common.doc.user (1.7.0.20090521092446) "Data Tools Platform User Documentation" [Starting]
        org.eclipse.datatools.connectivity (1.2.2.v201010220354) "Data Tools Platform Connectivity Plug-in" [Active]
        org.eclipse.datatools.connectivity.apache.derby (1.0.100.v200906020900) "Eclipse Data Tools Platform Derby Plug-in" [Active]
        org.eclipse.datatools.connectivity.apache.derby.dbdefinition (1.0.2.v200906161815) "Eclipse Data Tools Platform Apache Derby Database Definition" [Starting]
        org.eclipse.datatools.connectivity.apache.derby.ui (1.0.3.v201007080903) "Eclipse Data Tools Platform Apache Derby UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.console.profile (1.0.0.v200906020553) "DTP Connection Profiles Storage File Editor Plug-in" [Starting]
        org.eclipse.datatools.connectivity.db.generic (1.0.1.v200908130547) "Eclipse Data Tools Platform Generic DB Connectivity Plug-in" [Starting]
        org.eclipse.datatools.connectivity.db.generic.ui (1.0.1.v201004070709) "Eclipse Data Tools Platform Generic DB UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.dbdefinition.genericJDBC (1.0.1.v200906161815) "Eclipse Data Tools Platform DBDefinition Generic JDBC Plug-in" [Starting]
        org.eclipse.datatools.connectivity.doc.user (1.7.0.20090521092446) "Data Tools Platform Connectivity User Documentation" [Starting]
        org.eclipse.datatools.connectivity.doc.user.contexts (1.7.0.20090521092446) "Data Tools Platform Connectivity User Documentation for context-sensitive help" [Starting]
        org.eclipse.datatools.connectivity.oda (3.3.1.v201102051100) "DTP Open Data Access" [Starting]
        org.eclipse.datatools.connectivity.oda.consumer (3.2.3.v201102051100) "DTP ODA Consumer Helper Component Plug-in" [Starting]
        org.eclipse.datatools.connectivity.oda.design (3.3.2.v201012150951) "DTP ODA Design Session Model" [Starting]
        org.eclipse.datatools.connectivity.oda.design.ui (3.2.4.v201012150951) "DTP ODA Designer UI Framework Plug-in" [Starting]
        org.eclipse.datatools.connectivity.oda.flatfile (3.1.1.v201101261130) "Eclipse Data Tools Platform Flat File ODA Runtime Driver" [Starting]
        org.eclipse.datatools.connectivity.oda.flatfile.ui (3.1.1.v201101261130) "Eclipse Data Tools Platform Flat File ODA Designer" [Starting]
        org.eclipse.datatools.connectivity.oda.profile (3.2.4.v201007150318) "DTP ODA Connection Profile Framework Plug-in" [Starting]
        org.eclipse.datatools.connectivity.oda.template.ui (3.2.1.v201004090942) "DTP ODA New Plug-in Template Wizard" [Starting]
        org.eclipse.datatools.connectivity.sqm.core (1.2.1.v201010090204) "Eclipse Data Tools Platform SQM Core Plug-in" [Active]
        org.eclipse.datatools.connectivity.sqm.core.ui (1.2.0.v201002281800) "Eclipse Data Tools Platform SQM UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.sqm.server.ui (1.1.100.v201009280455) "Eclipse Data Tools Platform Server UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.ui (1.2.1.v201010211415) "Data Tools Platform Connectivity UI Plug-in" [Starting]
        org.eclipse.datatools.connectivity.ui.dse (1.1.4.v201004270430) "Eclipse Data Tools Platform Data Source Explorer Plug-in" [Starting]
        org.eclipse.datatools.doc.user (1.7.0.20090521092446) "Data Tool Platform User Documentation" [Starting]
        org.eclipse.datatools.enablement.finfo (1.5.1.v200906161800) "Eclipse Data Tools Platform Enablement" [Starting]
        org.eclipse.datatools.enablement.hsqldb (1.0.0.v200906020900) "Eclipse Data Tools Platform HSQLDB Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.hsqldb.dbdefinition (1.0.0.v200906161800) "Eclipse Data Tools Platform HSQLDB Database Definition Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.hsqldb.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform HSQLDB UI Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.iseries (1.0.2.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB iSeries Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.iseries.dbdefinition (1.0.3.v200906161800) "DB2 UDB iSeries Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.iseries.ui (1.0.1.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB UI iSeries Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.luw (1.0.2.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB LUW Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.luw.dbdefinition (1.0.4.v201005211215) "Eclipse Data Tools Platform DB2 UDB Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.luw.ui (1.0.2.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB LUW UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.zseries (1.0.2.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB zSeries Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.zseries.dbdefinition (1.0.4.v201005211230) "DB2 UDB Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.db2.zseries.ui (1.0.1.v201005211230) "Eclipse Data Tools Platform IBM DB2 UDB zSeries UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.informix (1.0.1.v201005211230) "Eclipse Data Tools Platform Informix Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.informix.dbdefinition (1.0.4.v201005211230) "Eclipse Data Tools Platform Informix Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.informix.ui (1.0.2.v201005211230) "Eclipse Data Tools Platform Informix UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.ibm.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform IBM UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.ingres (1.0.0.v200906111150) "Ingres DTP Plug-in" [Starting]
        org.eclipse.datatools.enablement.ingres.dbdefinition (1.0.0.v200906161800) "Ingres DTP Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.ingres.ui (1.0.0.v201006242214) "Ingres DTP UI Plug-in" [Active]
        org.eclipse.datatools.enablement.jdt.classpath (1.0.1.v201004070709) "Data Tools Platform Connectivity JDT Extension Plug-in" [Starting]
        org.eclipse.datatools.enablement.msft.sqlserver (1.0.1.v201001180222) "Eclipse Data Tools Platform Microsoft SQL Server Plug-in" [Active]
        org.eclipse.datatools.enablement.msft.sqlserver.dbdefinition (1.0.0.v201004211630) "Eclipse Data Tools Platform SQL Server Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.msft.sqlserver.ui (1.0.1.v200908130512) "Eclipse Data Tools Platform Microsoft SQL Server UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.mysql (1.0.2.v201002041100) "Eclipse Data Tools Platform MySQL Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.mysql.dbdefinition (1.0.4.v200906161800) "Eclipse Data Tools Platform MySQL Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.mysql.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform MySQL UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.oda.ws (1.2.2.v201010151422) "Eclipse Data Tools Platform Web Services ODA Runtime Driver" [Starting]
        org.eclipse.datatools.enablement.oda.ws.ui (1.2.2.v201012301630) "Eclipse Data Tools Platform Web Services ODA Designer" [Starting]
        org.eclipse.datatools.enablement.oda.xml (1.2.1.v201010211755) "Eclipse Data Tools Platform XML ODA Runtime Driver" [Starting]
        org.eclipse.datatools.enablement.oda.xml.ui (1.2.1.v201012161115) "Eclipse Data Tools Platform XML ODA Designer" [Starting]
        org.eclipse.datatools.enablement.oracle (1.0.0.v200908130544) "Eclipse Data Tools Platform Oracle Plug-in" [Active]
        org.eclipse.datatools.enablement.oracle.dbdefinition (1.0.102.v201101120730) "Eclipse Data Tools Platform Oracle Database Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.oracle.ui (1.0.2.v201005051303) "Eclipse Data Tools Platform Oracle UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.postgresql (1.0.1.v200906020900) "PostgreSQL Connection Profile and Driver Template Plug-in" [Starting]
        org.eclipse.datatools.enablement.postgresql.dbdefinition (1.0.1.v200906161800) "PostgreSQL DB Definition" [Starting]
        org.eclipse.datatools.enablement.postgresql.ui (1.0.0.v200906020900) "PostgreSQL Connection Profile and Driver Template UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.sap.maxdb (1.0.0.v200906020900) "Eclipse Data Tools Platform MaxDB Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.sap.maxdb.dbdefinition (1.0.0.v200906161800) "Eclipse Data Tools Platform MaxDB Definition Plug-in" [Starting]
        org.eclipse.datatools.enablement.sap.maxdb.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform MaxDB UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.sqlite (1.0.0.v201002041100) "Eclipse Data Tools Platform SQLite Enablement Plug-in" [Active]
        org.eclipse.datatools.enablement.sqlite.dbdefinition (1.0.1.v201002041100) "Eclipse Data Tools Platform SQLite Database Definition Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.sqlite.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform SQLite UI Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase (1.0.1.v200906020900) "High-level Sybase Enablement Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase.asa (1.0.1.v200906020900) "Sybase ASA Plug-in" [Active]
        org.eclipse.datatools.enablement.sybase.asa.dbdefinition (1.0.0.v200906161800) "Eclipse Data Tools Platform Sybase ASA Database Definition" [Starting]
        org.eclipse.datatools.enablement.sybase.asa.models (1.0.0.v201010140307) "Sybase ASA SQL Model" [Active]
        org.eclipse.datatools.enablement.sybase.asa.schemaobjecteditor.examples (2.5.0.200810071) "Sybase ASA Schema Object Editor" [Active]
        org.eclipse.datatools.enablement.sybase.asa.ui (1.0.1.v200906111150) "Sybase ASA Connection Profile UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase.ase (1.0.1.v200906020900) "JDBC/Sybase ASE Connection Profile Plug-in" [Active]
        org.eclipse.datatools.enablement.sybase.ase.dbdefinition (1.0.0.v200906161800) "Eclipse Data Tools Platform Sybase ASE Database Definition" [Starting]
        org.eclipse.datatools.enablement.sybase.ase.models (1.0.1.v201010140307) "Sybase ASE Model Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase.ase.ui (1.0.1.v200906020900) "ASE Enablement UI Plug-in" [Starting]
        org.eclipse.datatools.enablement.sybase.models (1.0.0.v201010140307) "Sybase Model Plug-in" [Active]
        org.eclipse.datatools.enablement.sybase.ui (1.0.0.v200906090458) "Sybase UI Plug-in" [Starting]
        org.eclipse.datatools.help (1.5.0.v200906020553) "Data Tools Platform Help Utilities" [Resolved]
        org.eclipse.datatools.intro (1.7.0.v201005281800) "Eclipse Data Tools Platform Intro Plug-in" [Resolved]
        org.eclipse.datatools.modelbase.dbdefinition (1.0.2.v201002130228) "Eclipse Data Tools Platform DBDefinition Model" [Starting]
        org.eclipse.datatools.modelbase.derby (1.0.0.v201002161452) "Eclipse Data Tools Platform Derby Model Plug-in" [Starting]
        org.eclipse.datatools.modelbase.sql (1.0.4.v201002250945) "Eclipse Data Tools Platform SQLModel Plug-in" [Active]
        org.eclipse.datatools.modelbase.sql.edit (1.0.1.v201002161452) "Eclipse Data Tools Platform SQLModel Edit Plug-in" [Starting]
        org.eclipse.datatools.modelbase.sql.query (1.1.1.v201008100700) "Eclipse Data Tools Platform SQL Query Model Plugin" [Starting]
        org.eclipse.datatools.modelbase.sql.query.edit (1.0.0.v200906022249) "SQL Query Edit Support Plugin" [Starting]
        org.eclipse.datatools.modelbase.sql.xml.query (1.0.1.v201004291415) "Eclipse Data Tools Platform SQL XML Query Model Plugin" [Starting]
        org.eclipse.datatools.oda.cshelp (1.1.1.v200907031118) "DTP ODA Context-sensitive Help" [Starting]
        org.eclipse.datatools.sqltools.common.ui (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL Tools Common UI Plug-in" [Active]
        org.eclipse.datatools.sqltools.data.core (1.2.0.v201005241300) "Data Core Plugin" [Starting]
        org.eclipse.datatools.sqltools.data.ui (1.2.0.v201005250945) "Data UI Plugin" [Starting]
        org.eclipse.datatools.sqltools.db.derby (1.0.0.v200906020900) "Eclipse Data Tools Platform Derby SQL Tools Plug-in" [Active]
        org.eclipse.datatools.sqltools.db.derby.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform Derby SQL Tools UI Plug-in" [Active]
        org.eclipse.datatools.sqltools.db.generic (1.0.0.v200906020900) "Eclipse Data Tools Platform SQL Tools Generic Database Plug-in" [Active]
        org.eclipse.datatools.sqltools.db.generic.ui (1.0.0.v200906020900) "Eclipse Data Tools Platform SQL Tools Generic Database UI Plug-in" [Active]
        org.eclipse.datatools.sqltools.ddlgen.ui (1.0.1.v201002270530) "Eclipse Data Tools Platform FE UI Plug-in" [Starting]
        org.eclipse.datatools.sqltools.debugger.core (1.0.1.v201005250945) "Eclipse Data Tools Platform SQL Debugger Framework" [Active]
        org.eclipse.datatools.sqltools.debugger.core.ui (1.0.0.v201003161000) "Eclipse Data Tools Platform SQL Debugger UI Framework" [Active]
        org.eclipse.datatools.sqltools.doc.user (1.7.0.20090521092446) "Data Tools Platform SQL Tools User Documentation" [Starting]
        org.eclipse.datatools.sqltools.doc.user.contexts (1.7.0.20090521092446) "Data Tools Platform SQL Tools User Documentation for context-sensitive help" [Starting]
        org.eclipse.datatools.sqltools.editor.core (1.0.0.v201001150815) "Eclipse Data Tools Platform SQL Editor Core Plug-in" [Active]
        org.eclipse.datatools.sqltools.editor.core.ui (1.0.0.v201001150815) "Eclipse Data Tools Platform SQL Editor Core UI Plug-in" [Active]
        org.eclipse.datatools.sqltools.parsers.sql (1.0.2.v201004291415) "Eclipse Data Tools Platform SQL Parser Plugin" [Starting]
        org.eclipse.datatools.sqltools.parsers.sql.lexer (1.0.1.v200906030654) "Eclipse Data Tools Platform Lexer Plug-in" [Starting]
        org.eclipse.datatools.sqltools.parsers.sql.query (1.2.0.v201004291415) "Eclipse Data Tools Platform SQL Query Parser Plugin" [Starting]
        org.eclipse.datatools.sqltools.parsers.sql.xml.query (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL XML Query Parser Plugin" [Starting]
        org.eclipse.datatools.sqltools.plan (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL Execution Plan View Plug-in" [Starting]
        org.eclipse.datatools.sqltools.result (1.1.0.v201005260930) "Eclipse Data Tools Platform SQL Results View Plug-ins" [Starting]
        org.eclipse.datatools.sqltools.result.ui (1.1.1.v201101140400) "Eclipse Data Tools Platform SQL Results View UI Plug-in" [Starting]
        org.eclipse.datatools.sqltools.routineeditor (1.0.0.v201003161000) "Eclipse Data Tools Platform SQL Tools Routine Editor Plug-in" [Starting]
        org.eclipse.datatools.sqltools.routineeditor.ui (1.0.1.v201004060545) "Eclipse Data Tools Platform SQL Tools Routine Editor UI Plug-in" [Starting]
        org.eclipse.datatools.sqltools.schemaobjecteditor (1.1.0.v200906022302) "Schema Object Editor Plug-in" [Starting]
        org.eclipse.datatools.sqltools.schemaobjecteditor.ui (1.1.1.200810071) "Schema Object Editor Framework" [Starting]
        org.eclipse.datatools.sqltools.schemaobjecteditor.ui.pages (1.1.0.200810071) "Schema Object Editor Pages Plug-in" [Starting]
        org.eclipse.datatools.sqltools.sql (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL Core Plug-in" [Active]
        org.eclipse.datatools.sqltools.sql.ui (1.0.0.v200906022302) "Eclipse Data Tools Platform SQL Core UI Plug-in" [Starting]
        org.eclipse.datatools.sqltools.sqlbuilder (1.0.3.v201009131745) "SQL Builder" [Starting]
        org.eclipse.datatools.sqltools.sqleditor (1.0.2.v201009230800) "Eclipse Data Tools Platform SQL Editor" [Active]
        org.eclipse.datatools.sqltools.sqlscrapbook (1.0.1.v201005250945) "Eclipse Data Tools Platform Sqlscrapbook Plug-in" [Active]
        org.eclipse.datatools.sqltools.tabledataeditor (1.0.1.v201005250945) "Eclipse Data Tools Platform Table Data Editor Plug-in" [Starting]
        org.eclipse.debug.core (3.6.0.v20100519) "Debug Core" [Active]
        org.eclipse.debug.ui (3.6.3.v20101201_r362) "Debug UI" [Active]
        org.eclipse.draw2d (3.6.2.v20110128-0100) "Graphical Editing Framework Draw2d" [Active]
        org.eclipse.dstore.core (3.2.2.R32x_v201102121806) "RSE DStore Core" [Starting]
        org.eclipse.dstore.extra (2.1.101.v200907301400) "RSE DStore Platform Support" [Starting]
        org.eclipse.ecf (3.1.0.v20100906-1425) "ECF Core API" [Active]
        org.eclipse.ecf.filetransfer (4.0.0.v20100906-1425) "ECF Filetransfer API" [Active]
        org.eclipse.ecf.identity (3.1.0.v20100906-1425) "ECF Identity API" [Active]
        org.eclipse.ecf.provider.filetransfer (3.1.0.v20100906-1425) "ECF Filetransfer Provider" [Active]
        org.eclipse.ecf.provider.filetransfer.httpclient (4.0.0.v20100906-1425) "ECF HttpClient Filetransfer Provider" [Active]
        org.eclipse.ecf.provider.filetransfer.httpclient.ssl (1.0.0.v20100906-1425) "ECF Filetransfer Httpclient SSL Fragment" [Resolved]
        org.eclipse.ecf.provider.filetransfer.ssl (1.0.0.v20100906-1425) "ECF Filetransfer SSL Fragment" [Resolved]
        org.eclipse.ecf.ssl (1.0.100.v20100906-1425) "ECF SSL Fragment" [Resolved]
        org.eclipse.egit (0.12.1) "Git Team Provider (Incubation)" [Starting]
        org.eclipse.egit.core (0.12.1) "Git Team Provider Core (Incubation)" [Active]
        org.eclipse.egit.doc (0.12.1) "Git Team Provider Documentation (Incubation)" [Resolved]
        org.eclipse.egit.ui (0.12.1) "Git Team Provider UI (Incubation)" [Active]
        org.eclipse.emf (2.6.0.v20100914-1218) "EMF - Eclipse Modeling Framework Runtime and Tools" [Starting]
        org.eclipse.emf.ant (2.6.1.v20100905-1631) "EMF Ant Tasks" [Starting]
        org.eclipse.emf.codegen (2.6.0.v20100914-1218) "EMF Code Generation" [Starting]
        org.eclipse.emf.codegen.ecore (2.6.1.v20100914-1218) "EMF Ecore Code Generator" [Starting]
        org.eclipse.emf.codegen.ecore.ui (2.6.0.v20100914-1218) "EMF Ecore Code Generator UI" [Starting]
        org.eclipse.emf.codegen.ui (2.6.0.v20100914-1218) "EMF Code Generation UI" [Starting]
        org.eclipse.emf.common (2.6.0.v20100914-1218) "EMF Common" [Active]
        org.eclipse.emf.common.ui (2.6.0.v20100914-1218) "EMF Common UI" [Starting]
        org.eclipse.emf.converter (2.5.0.v20100914-1218) "EMF Model Converter" [Starting]
        org.eclipse.emf.databinding (1.2.0.v20100914-1218) "EMF Data Binding" [Starting]
        org.eclipse.emf.databinding.edit (1.2.0.v20100914-1218) "EMF Edit Data Binding" [Starting]
        org.eclipse.emf.ecore (2.6.1.v20100914-1218) "EMF Ecore" [Active]
        org.eclipse.emf.ecore.change (2.5.1.v20100907-1643) "EMF Change Model" [Starting]
        org.eclipse.emf.ecore.change.edit (2.5.0.v20100521-1846) "EMF Change Edit" [Starting]
        org.eclipse.emf.ecore.edit (2.6.0.v20100914-1218) "EMF Ecore Edit" [Starting]
        org.eclipse.emf.ecore.editor (2.6.0.v20100914-1218) "EMF Sample Ecore Editor" [Starting]
        org.eclipse.emf.ecore.xmi (2.5.0.v20100521-1846) "EMF XML/XMI Persistence" [Active]
        org.eclipse.emf.edit (2.6.0.v20100914-1218) "EMF Edit" [Active]
        org.eclipse.emf.edit.ui (2.6.0.v20100914-1218) "EMF Edit UI" [Starting]
        org.eclipse.emf.exporter (2.6.0.v20100521-1846) "EMF Model Exporter" [Starting]
        org.eclipse.emf.importer (2.6.0.v20100521-1846) "EMF Model Importer" [Starting]
        org.eclipse.emf.importer.ecore (2.6.0.v20100521-1846) "EMF Ecore Importer" [Starting]
        org.eclipse.emf.importer.java (2.6.0.v20100521-1846) "EMF Annotated Java Importer" [Starting]
        org.eclipse.emf.importer.rose (2.6.0.v20100521-1846) "EMF Rose Importer" [Starting]
        org.eclipse.emf.mapping (2.6.0.v20100914-1218) "EMF Mapping" [Starting]
        org.eclipse.emf.mapping.ecore (2.6.0.v20100914-1218) "EMF Ecore Mapping" [Starting]
        org.eclipse.emf.mapping.ecore.editor (2.6.0.v20100914-1218) "EMF Ecore Mapping Editor" [Starting]
        org.eclipse.emf.mapping.ecore2ecore (2.5.0.v20100521-1847) "EMF Ecore to Ecore Mapping" [Starting]
        org.eclipse.emf.mapping.ecore2ecore.editor (2.4.0.v20100521-1847) "EMF Ecore to Ecore Mapping Editor" [Starting]
        org.eclipse.emf.mapping.ecore2xml (2.5.0.v20100521-1847) "EMF Ecore to XML Mapping" [Starting]
        org.eclipse.emf.mapping.ecore2xml.ui (2.5.0.v20100521-1847) "EMF Ecore to XML Mapping Editor" [Starting]
        org.eclipse.emf.mapping.ui (2.6.0.v20100914-1218) "EMF Mapping UI" [Starting]
        org.eclipse.equinox.app (1.3.1.R36x_v20100803) "Equinox Application Container" [Active]
        org.eclipse.equinox.common (3.6.0.v20100503) "Common Eclipse Runtime" [Active]
        org.eclipse.equinox.concurrent (1.0.100.v20100503) "Equinox Concurrent API" [Starting]
        org.eclipse.equinox.ds (1.2.1.R36x_v20100803) "Declarative Services" [Active]
        org.eclipse.equinox.event (1.2.0.v20100503) "Event Admin" [Starting]
        org.eclipse.equinox.frameworkadmin (2.0.0.v20100503) "Equinox Framework Admin" [Active]
        org.eclipse.equinox.frameworkadmin.equinox (1.0.200.v20100505) "Equinox Framework Admin for Equinox" [Starting]
        org.eclipse.equinox.http.jetty (2.0.0.v20100503) "Jetty Http Service" [Active]
        org.eclipse.equinox.http.registry (1.1.1.R36x_v20101103) "Http Service Registry Extensions" [Active]
        org.eclipse.equinox.http.servlet (1.1.0.v20100503) "Http Services Servlet" [Active]
        org.eclipse.equinox.jsp.jasper (1.0.201.R36x_v20101103) "Jasper Jsp Support Bundle" [Starting]
        org.eclipse.equinox.jsp.jasper.registry (1.0.200.v20100503) "Jasper Jsp Registry Support Plug-in" [Starting]
        org.eclipse.equinox.launcher (1.1.1.R36x_v20101122_1400) "Equinox Launcher" [Resolved]
        org.eclipse.equinox.launcher.gtk.linux.x86 (1.1.2.R36x_v20101019_1345) "Equinox Launcher Linux X86 Fragment" [Resolved]
        org.eclipse.equinox.p2.artifact.repository (1.1.1.R36x_v20100901) "Equinox Provisioning Artifact Repository Support" [Active]
        org.eclipse.equinox.p2.console (1.0.200.v20100601) "Equinox Provisioning Console" [Starting]
        org.eclipse.equinox.p2.core (2.0.3.R36x_v20110111) "Equinox Provisioning Core" [Active]
        org.eclipse.equinox.p2.director (2.0.3.R36x_v20101117-1018) "Equinox Provisioning Director" [Active]
        org.eclipse.equinox.p2.director.app (1.0.201.R36x_v20100823) "Equinox Provisioning Director Application" [Starting]
        org.eclipse.equinox.p2.directorywatcher (1.0.203.R36x_v20101220) "Equinox Provisioning Directory Watcher" [Active]
        org.eclipse.equinox.p2.engine (2.0.1.R36x_v20110201) "Equinox Provisioning Engine" [Active]
        org.eclipse.equinox.p2.extensionlocation (1.2.0.v20100518) "Extension Location Repository Support" [Active]
        org.eclipse.equinox.p2.garbagecollector (1.0.100.v20100503) "Provisioning Garbage Collector" [Active]
        org.eclipse.equinox.p2.jarprocessor (1.0.200.v20100503a) "Equinox Provisioning JAR Processor" [Resolved]
        org.eclipse.equinox.p2.metadata (2.0.1.R36x_v20101202) "Equinox Provisioning Metadata" [Active]
        org.eclipse.equinox.p2.metadata.generator (1.0.202.R36x_v20101208-1400) "Equinox Provisioning Metadata Generator" [Starting]
        org.eclipse.equinox.p2.metadata.repository (1.1.0.v20100513) "Equinox Provisioning Metadata Repository" [Active]
        org.eclipse.equinox.p2.operations (2.0.0.v20100510) "Equinox Provisioning Update Checker" [Active]
        org.eclipse.equinox.p2.publisher (1.1.2.v20100824-2220) "Equinox Provisioning Publisher" [Active]
        org.eclipse.equinox.p2.ql (2.0.0.v20100503a) "p2 query language" [Starting]
        org.eclipse.equinox.p2.reconciler.dropins (1.1.2.R36x_v20110114) "Dropin Reconciler Plug-in" [Active]
        org.eclipse.equinox.p2.repository (2.0.2.R36x_v20110111-1500) "Equinox Provisioning Repository" [Active]
        org.eclipse.equinox.p2.repository.tools (2.0.1.R36x_v20100823) "Equinox p2 repository tools." [Starting]
        org.eclipse.equinox.p2.touchpoint.eclipse (2.0.3.R36x_v20101202) "Equinox Provisioning Eclipse Touchpoint" [Active]
        org.eclipse.equinox.p2.touchpoint.natives (1.0.201.R36x_v20110111) "Equinox Provisioning Native Touchpoint" [Starting]
        org.eclipse.equinox.p2.ui (2.0.0.v20100518) "Equinox Provisioning UI Support" [Active]
        org.eclipse.equinox.p2.ui.sdk (1.0.100.v20100513) "Equinox Provisioning Platform Update Support" [Active]
        org.eclipse.equinox.p2.ui.sdk.scheduler (1.0.0.v20100507-1815) "Equinox Provisioning Platform Automatic Update Support" [Active]
        org.eclipse.equinox.p2.updatechecker (1.1.101.R36x_v20100823) "Equinox Provisioning Update Checker" [Active]
        org.eclipse.equinox.p2.updatesite (1.0.201.R36x_v20100823) "Update site repository adapter bundle (Incubation)" [Starting]
        org.eclipse.equinox.preferences (3.3.0.v20100503) "Eclipse Preferences Mechanism" [Active]
        org.eclipse.equinox.registry (3.5.0.v20100503) "Extension Registry Support" [Active]
        org.eclipse.equinox.security (1.0.200.v20100503) "Equinox Java Authentication and Authorization Service (JAAS)" [Active]
        org.eclipse.equinox.security.ui (1.0.200.v20100503) "Equinox Security Default UI" [Active]
        org.eclipse.equinox.simpleconfigurator (1.0.200.v20100503) "Simple Configurator" [Active]
        org.eclipse.equinox.simpleconfigurator.manipulator (2.0.0.v20100503) "Simple Configurator Manipulator" [Active]
        org.eclipse.equinox.util (1.0.200.v20100503) "Equinox Util Bundle" [Active]
        org.eclipse.equinox.weaving.aspectj (1.0.0.v20100108) "WeavingService Plug-in (Incubation)" [Active]
        org.eclipse.equinox.weaving.caching (1.0.0.v20100108) "Standard Caching Service for Equinox Aspects (Incubation)" [Active]
        org.eclipse.equinox.weaving.caching.j9 (1.0.0.v20100108) "J9 CachingService Plug-in (Incubation)" [Active]
        org.eclipse.equinox.weaving.hook (1.0.0.v20100108) "Aspect Weaving Hooks Plug-in (Incubation)" [Resolved]
        org.eclipse.gef (3.6.2.v20110110-2020) "Graphical Editing Framework GEF" [Active]
        org.eclipse.help (3.5.0.v20100524) "Help System Core" [Active]
        org.eclipse.help.appserver (3.1.400.v20100427) "Help Application Server" [Starting]
        org.eclipse.help.base (3.5.3.v201102101200) "Help System Base" [Active]
        org.eclipse.help.ui (3.5.3.r36_20101116) "Help System UI" [Active]
        org.eclipse.help.webapp (3.5.3.r36_20101130) "Help System Webapp" [Starting]
        org.eclipse.jdt (3.6.1.v201102101200) "Eclipse Java Development Tools" [Resolved]
        org.eclipse.jdt.apt.core (3.3.402.R36_v20110120-1000) "Java Annotation Processing Core" [Active]
        org.eclipse.jdt.apt.pluggable.core (1.0.301.R36_v20100727-0110) "Java Compiler Apt IDE" [Active]
        org.eclipse.jdt.apt.ui (3.3.300.v20100513-0845) "Java Annotation Processing UI" [Starting]
        org.eclipse.jdt.compiler.apt (1.0.300.v20100513-0845) "Java Compiler Apt" [Resolved]
        org.eclipse.jdt.compiler.tool (1.0.100.v_A76_R36x) "Java Compiler Tool Support" [Resolved]
        org.eclipse.jdt.core (3.6.2.xx-20110602-1000-e36) "Java Development Tools Core" [Active]
        org.eclipse.jdt.core.manipulation (1.3.0.v20100520-0800) "Java Code Manipulation Functionality" [Active]
        org.eclipse.jdt.debug (3.6.1.v20100715_r361) "JDI Debug Model" [Active]
        org.eclipse.jdt.debug.ui (3.5.2.v20100928a_r362) "JDI Debug UI" [Active]
        org.eclipse.jdt.doc.user (3.6.1.r361_v20100721-0800) "Eclipse Java development user guide" [Resolved]
        org.eclipse.jdt.groovy.core (2.5.1.xx-20110602-1000-e36) "Eclipse-Groovy Integration Plug-in" [Active]
        org.eclipse.jdt.junit (3.6.1.r361_v20100825-0800) "Java Development Tools JUnit support" [Active]
        org.eclipse.jdt.junit.core (3.6.1.r361_v20100825-0800) "Java Development Tools JUnit core support" [Active]
        org.eclipse.jdt.junit.runtime (3.4.200.v20100526-0800) "Java Development Tools JUnit Runtime Support" [Resolved]
        org.eclipse.jdt.junit4.runtime (1.1.100.v20100526-0800) "Java Development Tools JUnit4 Runtime Support" [Resolved]
        org.eclipse.jdt.launching (3.5.200.v20110105_r362) "Java Development Tools Launching Support" [Active]
        org.eclipse.jdt.ui (3.6.2.r362_v20110203) "Java Development Tools UI" [Active]
        org.eclipse.jem (2.0.400.v201005110200) "Java EMF Model" [Active]
        org.eclipse.jem.beaninfo (2.0.300.v200905030615) "Java EMF Model BeanInfo (Introspection) Support" [Starting]
        org.eclipse.jem.beaninfo.vm (2.0.300.v201004110600) "JEM Beaninfo VM Jar" [Resolved]
        org.eclipse.jem.beaninfo.vm.common (2.0.300.v201004110600) "JEM Beaninfo Common Jar" [Resolved]
        org.eclipse.jem.proxy (2.0.301.v201101101700) "Java EMF Model Proxy Support" [Starting]
        org.eclipse.jem.util (2.1.3.v201012070000) "Java EMF Model Utilities" [Active]
        org.eclipse.jem.workbench (2.0.300.v200910290230) "Java EMF Model Workbench Support" [Active]
        org.eclipse.jface (3.6.2.M20110210-1200) "JFace" [Active]
        org.eclipse.jface.databinding (1.4.0.I20100601-0800) "JFace Data Binding for SWT and JFace" [Resolved]
        org.eclipse.jface.text (3.6.1.r361_v20100825-0800) "JFace Text" [Resolved]
        org.eclipse.jgit (0.12.1) "JGit Core (Incubation)" [Active]
        org.eclipse.jpt.branding (2.3.2.v201008242310) "Dali Java Persistence Tools" [Resolved]
        org.eclipse.jpt.core (2.3.3.v201102172310) "Dali Java Persistence Tools - Core" [Starting]
        org.eclipse.jpt.db (1.2.202.v201010192330) "Dali Java Persistence Tools - DB" [Starting]
        org.eclipse.jpt.db.ui (1.1.200.v201003290000) "Dali Java Persistence Tools - DB UI" [Resolved]
        org.eclipse.jpt.doc.user (1.3.1.v201007142310) "Dali Java Persistence Tools - Documentation" [Resolved]
        org.eclipse.jpt.eclipselink.branding (2.3.2.v201008242310) "Dali Java Persistence Tools - EclipseLink Support" [Resolved]
        org.eclipse.jpt.eclipselink.core (1.3.2.v201102072310) "Dali Java Persistence Tools - EclipseLink Support - Core" [Starting]
        org.eclipse.jpt.eclipselink.core.ddlgen (1.0.300.v201003290000) "Dali Java Persistence Tools - EclipseLink Support - DDL Generation" [Resolved]
        org.eclipse.jpt.eclipselink.jaxb.core.schemagen (1.0.0.v201005120000) "Dali Java Persistence Tools - EclipseLink JAXB Support - Schema Generation" [Resolved]
        org.eclipse.jpt.eclipselink.ui (1.3.0.v201004280001) "Dali Java Persistence Tools - EclipseLink Support - UI" [Starting]
        org.eclipse.jpt.gen (1.3.100.v201004260000) "Dali Java Persistence Tools - Entity Gen" [Resolved]
        org.eclipse.jpt.jaxb.core.schemagen (1.0.1.v201006300000) "Dali Java Persistence Tools - JAXB Support - Schema Generation" [Resolved]
        org.eclipse.jpt.jaxb.ui (1.0.1.v201006300000) "Dali Java Persistence Tools - JAXB Support - UI" [Starting]
        org.eclipse.jpt.ui (2.3.2.v201008252310) "Dali Java Persistence Tools - UI" [Starting]
        org.eclipse.jpt.utility (1.5.0.v201005100000) "Dali Java Persistence Tools - Utility" [Resolved]
        org.eclipse.jsch.core (1.1.200.I20100505-1245) "JSch Core" [Active]
        org.eclipse.jsch.ui (1.1.300.I20100505-1245) "JSch UI" [Starting]
        org.eclipse.jsf.branding (3.2.0.v20100522) "JavaServer Faces Tools" [Resolved]
        org.eclipse.jst.common.annotations.controller (1.1.300.v200908252030) "Annotation Controller Plug-in" [Resolved]
        org.eclipse.jst.common.annotations.core (1.1.300.v201004141630) "Annotation Core Plug-in" [Resolved]
        org.eclipse.jst.common.annotations.ui (1.1.300.v201002081900) "Annotations UI Plug-in" [Starting]
        org.eclipse.jst.common.frameworks (1.1.403.v201012160000) "Integration Plug-in" [Active]
        org.eclipse.jst.common.project.facet.core (1.4.102.v201008182136) "Eclipse Faceted Project Framework JDT Enablement" [Active]
        org.eclipse.jst.common.project.facet.ui (1.4.102.v201008182136) "Eclipse Faceted Project Framework JDT Enablement UI" [Starting]
        org.eclipse.jst.common.ui (1.0.3.v201101101700) "Common JST UI Plug-in" [Starting]
        org.eclipse.jst.ejb.doc.user (1.1.200.v20100519) "EJB docs" [Starting]
        org.eclipse.jst.ejb.ui (1.1.502.v201101121843) "WTP EJB UI Plug-in" [Starting]
        org.eclipse.jst.ejb.ui.infopop (1.0.300.v2010022311013) "EJB infopop" [Starting]
        org.eclipse.jst.j2ee (1.1.404.v201102081800) "Java EE Component" [Active]
        org.eclipse.jst.j2ee.core (1.2.4.v201102101900) "J2EE Core Component" [Active]
        org.eclipse.jst.j2ee.doc.user (1.1.300.v201007141655) "J2EE tools documentation" [Resolved]
        org.eclipse.jst.j2ee.ejb (1.1.402.v201102071010) "EJB component Plug-in" [Starting]
        org.eclipse.jst.j2ee.ejb.annotation.model (1.1.300.v201003112036) "EJB Annotation Model Plug-in" [Starting]
        org.eclipse.jst.j2ee.ejb.annotations.emitter (1.1.200.v200909290826) "EJB Emitter Plug-in" [Starting]
        org.eclipse.jst.j2ee.ejb.annotations.ui (1.1.200.v201004290730) "EJB Annotations Ui Plug-in" [Starting]
        org.eclipse.jst.j2ee.ejb.annotations.xdoclet (1.2.100.v201003112036) "Xdoclet Annotations Plug-in" [Starting]
        org.eclipse.jst.j2ee.infopop (1.0.300.v200805140415) "J2EE tools infopops" [Resolved]
        org.eclipse.jst.j2ee.jca (1.1.400.v201005270700) "JCA Plug-in" [Starting]
        org.eclipse.jst.j2ee.jca.ui (1.1.400.v201004150700) "WTP JCA UI Plug-in" [Starting]
        org.eclipse.jst.j2ee.navigator.ui (1.1.403.v201012020600) "J2EE Extensions to Common Navigator" [Starting]
        org.eclipse.jst.j2ee.ui (1.1.404.v201101122300) "WTP J2EE UI Plug-in" [Active]
        org.eclipse.jst.j2ee.web (1.1.404.v201102030400) "Web Plug-in" [Active]
        org.eclipse.jst.j2ee.webservice (1.1.400.v201004110600) "Web Service Plug-in" [Starting]
        org.eclipse.jst.j2ee.webservice.ui (1.1.400.v201004110600) "WTP Webservice UI Plug-in" [Starting]
        org.eclipse.jst.j2ee.xdoclet.runtime (1.1.300.v201004280700) "XDocletRuntime Plug-in" [Starting]
        org.eclipse.jst.jee (1.0.302.v201101122300) "Java EE common Plug-in" [Active]
        org.eclipse.jst.jee.ejb (1.0.301.v201007070821) "Java EE Ejb Plug-in" [Starting]
        org.eclipse.jst.jee.ui (1.0.304.v201101272100) "Eclipse Java EE Developer Tools" [Starting]
        org.eclipse.jst.jee.web (1.0.301.v201007070907) "Java EE Web Plug-in" [Starting]
        org.eclipse.jst.jsf.apache.trinidad.tagsupport (1.1.101.v20100906) "JavaServer Faces Tools - Taglibrary Metadata (Apache Trinidad)" [Starting]
        org.eclipse.jst.jsf.common (1.2.2.v201101211220) "JavaServer Faces Tools - Common" [Active]
        org.eclipse.jst.jsf.common.runtime (1.1.0.v20100510) "JavaServer Faces Tools - Common Runtime" [Starting]
        org.eclipse.jst.jsf.common.ui (1.2.0.v20100329) "JavaServer Faces Tools - Common UI" [Starting]
        org.eclipse.jst.jsf.core (1.3.3.v201102021253) "JavaServer Faces Tools - Core" [Active]
        org.eclipse.jst.jsf.doc.user (1.2.1.v20100827) "JavaServer Faces Tools - User Guide" [Starting]
        org.eclipse.jst.jsf.facelet.core (1.0.2.v201101042130) "JSF Facelets Tools - WTP Incubator Project" [Starting]
        org.eclipse.jst.jsf.facelet.ui (1.0.0.v20100602) "UI Plug-in" [Starting]
        org.eclipse.jst.jsf.facesconfig (1.2.1.v20100906) "JavaServer Faces Tools - FacesConfig Model" [Starting]
        org.eclipse.jst.jsf.facesconfig.ui (1.2.1.v201101112207) "JavaServer Faces Tools - FacesConfig Editor" [Starting]
        org.eclipse.jst.jsf.standard.tagsupport (1.2.2.v20101027) "JavaServer Faces Tools - Taglibrary Metadata" [Starting]
        org.eclipse.jst.jsf.ui (1.3.1.v20100906) "JavaServer Faces Tools - UI" [Starting]
        org.eclipse.jst.jsp.core (1.2.304.v201102160550) "Structured Source JSP Model" [Active]
        org.eclipse.jst.jsp.ui (1.1.503.v201101262228) "SSE JSP Source Editor" [Active]
        org.eclipse.jst.jsp.ui.infopop (1.0.200.v201004150328) "JSP tools infopops" [Resolved]
        org.eclipse.jst.pagedesigner (1.3.2.v201101211220) "JavaServer Faces Tools - Web Page Editor" [Starting]
        org.eclipse.jst.pagedesigner.jsf.ui (1.2.0.v20100414) "JavaServer Faces Tools - Pagedesigner UI" [Starting]
        org.eclipse.jst.pagedesigner.jsp.core (1.2.0.v20100308) "JavaServer Faces Tools - JSP Core Pagedesigner" [Starting]
        org.eclipse.jst.server.core (1.2.101.v20100421) "Java Server Support" [Active]
        org.eclipse.jst.server.generic.core (1.0.606.v20100512) "Generic Server Plugin" [Starting]
        org.eclipse.jst.server.generic.jboss (1.6.1.v200904151730) "JBoss Generic server definitions" [Starting]
        org.eclipse.jst.server.generic.jonas (1.5.205.v200805140145) "JOnAS Generic Server definitions" [Starting]
        org.eclipse.jst.server.generic.oc4j (1.5.206.v20090812) "OC4J Generic server definitions" [Starting]
        org.eclipse.jst.server.generic.ui (1.0.505.v20100428) "Generic Server Plugin UI" [Starting]
        org.eclipse.jst.server.preview.adapter (1.1.100.v20100308) "JEE Preview Server Support" [Starting]
        org.eclipse.jst.server.tomcat.core (1.1.203.v20110201) "Apache Tomcat Support" [Active]
        org.eclipse.jst.server.tomcat.ui (1.1.200.v20100418) "Apache Tomcat UI Support" [Active]
        org.eclipse.jst.server.ui (1.1.101.v20100823b) "Java Server UI Support" [Starting]
        org.eclipse.jst.server.ui.doc.user (1.0.500.v201005192218) "Server Tools documentation for J2EE Standard Tools" [Starting]
        org.eclipse.jst.server.ui.infopop (1.0.400.v200805140145) "Server Tools infopops for J2EE Standard Tools" [Resolved]
        org.eclipse.jst.server.websphere.core (1.0.302.v20080620) "WebSphere Generic Server Definition Core Plug-in" [Starting]
        org.eclipse.jst.servlet.ui (1.1.404.v201101270100) "WTP Servlet UI Plug-in" [Starting]
        org.eclipse.jst.servlet.ui.infopop (1.0.300.v200805140415) "Servlet infopop" [Starting]
        org.eclipse.jst.standard.schemas (1.1.0.v201003031644) "Java EE Related Schemas" [Resolved]
        org.eclipse.jst.ws (1.0.507.v201004211805) "Web Services" [Starting]
        org.eclipse.jst.ws.axis.consumption.core (1.0.406.v201004211805) "Web service Axis Consumption Core" [Starting]
        org.eclipse.jst.ws.axis.consumption.ui (1.0.505.v201004211805) "Webservice Axis Consumption UI" [Starting]
        org.eclipse.jst.ws.axis.creation.ui (1.0.600.v201008171516) "Webservice Axis Creation UI" [Starting]
        org.eclipse.jst.ws.axis.infopop (1.0.300.v200805140230) "Web services Axis context sensitive help" [Starting]
        org.eclipse.jst.ws.axis.ui.doc.user (1.1.100.v201005192217) "Axis Web services documentation" [Resolved]
        org.eclipse.jst.ws.axis2.consumption.core (1.0.105.v201004211805) "Webservice Axis2 Consumption Core Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.consumption.ui (1.0.103.v201004211805) "Webservice Axis2 Consumption UI Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.core (1.0.204.v201004211805) "Webservice Axis2 Core Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.creation.core (1.0.106.v201004211805) "Webservice Axis2 Creation Core Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.creation.ui (1.0.104.v201004211805) "Webservice Axis2 Creation UI Plug-in" [Starting]
        org.eclipse.jst.ws.axis2.ui (1.0.303.v201003110431) "Axis2 Tools" [Starting]
        org.eclipse.jst.ws.axis2.ui.doc.user (1.0.100.v201005192217) "Axis2 Web services documentation" [Resolved]
        org.eclipse.jst.ws.consumption (1.0.507.v201004211805) "Web Services Consumption" [Starting]
        org.eclipse.jst.ws.consumption.infopop (1.0.300.v200805140230) "Web services UI" [Resolved]
        org.eclipse.jst.ws.consumption.ui (1.1.302.v201101191731) "Web Services Consumption Graphical User Interface" [Starting]
        org.eclipse.jst.ws.consumption.ui.doc.user (1.0.600.v201005192217) "Web service consumption documentation" [Starting]
        org.eclipse.jst.ws.creation.ejb.ui (1.0.201.v201004211805) "Web Services Creation EJB Graphical User Interface" [Resolved]
        org.eclipse.jst.ws.creation.ui (1.0.510.v201011041151) "Web Services Creation Graphical User Interface" [Starting]
        org.eclipse.jst.ws.doc.user (1.0.600.v201005192217) "Web Services UI" [Resolved]
        org.eclipse.jst.ws.infopop (1.0.300.v200805140230) "Web services UI" [Resolved]
        org.eclipse.jst.ws.jaxrs.core (1.0.201.v201011231540) "JAX-RS Tools - Core" [Active]
        org.eclipse.jst.ws.jaxrs.ui (1.0.301.v201012020511) "JAX-RS Tools - UI" [Starting]
        org.eclipse.jst.ws.uddiregistry (1.0.500.v201004211805) "Web Services Universal Description Discovery and Integration Registry" [Starting]
        org.eclipse.jst.ws.ui (1.0.403.v201004211805) "Web Services Graphical User Interface" [Starting]
        org.eclipse.ltk.core.refactoring (3.5.101.r362_v20101117-0800) "Refactoring Core" [Active]
        org.eclipse.ltk.ui.refactoring (3.5.0.v20100526-0800) "Refactoring UI" [Active]
        org.eclipse.mylyn (3.5.0.v20110316-0100) "Mylyn" [Resolved]
        org.eclipse.mylyn.bugzilla.core (3.5.0.v20110316-0100) "Mylyn Bugzilla Connector Core" [Active]
        org.eclipse.mylyn.bugzilla.ide (3.5.0.v20110316-0100) "Mylyn Bugzilla IDE Extensions" [Resolved]
        org.eclipse.mylyn.bugzilla.ui (3.5.0.v20110316-0100) "Mylyn Bugzilla Connector UI" [Active]
        org.eclipse.mylyn.commons.core (3.5.0.v20110316-0100) "Mylyn Commons Core" [Resolved]
        org.eclipse.mylyn.commons.net (3.5.0.v20110316-0100) "Mylyn Commons Net" [Active]
        org.eclipse.mylyn.commons.repositories (0.1.0.v20110316-0100) "Mylyn Commons" [Resolved]
        org.eclipse.mylyn.commons.screenshots (1.0.0.v20110316-0100) "Mylyn Commons" [Resolved]
        org.eclipse.mylyn.commons.soap (3.5.0.v20110316-0100) "Mylyn Commons Soap" [Resolved]
        org.eclipse.mylyn.commons.team (0.1.0.v20110316-0100) "Mylyn Commons" [Starting]
        org.eclipse.mylyn.commons.ui (3.5.0.v20110316-0100) "Mylyn Commons UI" [Active]
        org.eclipse.mylyn.commons.xmlrpc (3.5.0.v20110316-0100) "Mylyn XML-RPC Support" [Starting]
        org.eclipse.mylyn.context.core (3.5.0.v20110316-0100) "Mylyn Context Core" [Active]
        org.eclipse.mylyn.context.ui (3.5.0.v20110316-0100) "Mylyn Context UI" [Active]
        org.eclipse.mylyn.discovery.core (3.5.0.v20110316-0100) "Mylyn Connector Discovery Core" [Resolved]
        org.eclipse.mylyn.discovery.ui (3.5.0.v20110316-0100) "Mylyn Connector Discovery UI" [Resolved]
        org.eclipse.mylyn.help.ui (3.5.0.v20110316-0100) "Mylyn Help" [Starting]
        org.eclipse.mylyn.ide.ant (3.5.0.v20110316-0100) "Mylyn Ant Bridge" [Active]
        org.eclipse.mylyn.ide.ui (3.5.0.v20110316-0100) "Mylyn IDE UI" [Active]
        org.eclipse.mylyn.java.tasks (3.5.0.v20110316-0100) "Mylyn Java Tasks" [Active]
        org.eclipse.mylyn.java.ui (3.5.0.v20110316-0100) "Mylyn Java Bridge" [Active]
        org.eclipse.mylyn.jira.core (3.4.0) "Atlassian Connector for Eclipse replacement for Mylyn Jira Connector Core" [Starting]
        org.eclipse.mylyn.jira.ui (3.4.0) "Atlassian Connector for Eclipse replacement for Mylyn JIRA Connector UI" [Starting]
        org.eclipse.mylyn.monitor.core (3.5.0.v20110316-0100) "Mylyn Monitor Core" [Resolved]
        org.eclipse.mylyn.monitor.ui (3.5.0.v20110316-0100) "Mylyn Monitor UI" [Active]
        org.eclipse.mylyn.resources.ui (3.5.0.v20110316-0100) "Mylyn Resources UI" [Active]
        org.eclipse.mylyn.tasks.bugs (3.5.0.v20110316-0100) "Mylyn Bug Reporting" [Starting]
        org.eclipse.mylyn.tasks.core (3.5.0.v20110316-0100) "Mylyn Tasks Core" [Resolved]
        org.eclipse.mylyn.tasks.search (3.5.0.v20110316-0100) "Mylyn Tasks UI" [Resolved]
        org.eclipse.mylyn.tasks.ui (3.5.0.v20110316-0100) "Mylyn Tasks UI" [Active]
        org.eclipse.mylyn.team.cvs (3.5.0.v20110316-0100) "Mylyn CVS Extensions" [Resolved]
        org.eclipse.mylyn.team.ui (3.5.0.v20110316-0100) "Mylyn Team UI" [Active]
        org.eclipse.mylyn.wikitext.confluence.core (1.4.0.v20110316-0100) "Mylyn WikiText Confluence" [Resolved]
        org.eclipse.mylyn.wikitext.confluence.ui (1.4.0.v20110316-0100) "Mylyn WikiText Confluence UI" [Resolved]
        org.eclipse.mylyn.wikitext.core (1.4.0.v20110316-0100) "Mylyn WikiText" [Active]
        org.eclipse.mylyn.wikitext.help.ui (1.4.0.v20110316-0100) "Mylyn WikiText Help UI" [Resolved]
        org.eclipse.mylyn.wikitext.mediawiki.core (1.4.0.v20110316-0100) "Mylyn WikiText MediaWiki" [Resolved]
        org.eclipse.mylyn.wikitext.mediawiki.ui (1.4.0.v20110316-0100) "Mylyn WikiText MediaWiki UI" [Resolved]
        org.eclipse.mylyn.wikitext.tasks.ui (1.4.0.v20110316-0100) "Mylyn WikiText Tasks UI" [Active]
        org.eclipse.mylyn.wikitext.textile.core (1.4.0.v20110316-0100) "Mylyn WikiText Textile" [Resolved]
        org.eclipse.mylyn.wikitext.textile.ui (1.4.0.v20110316-0100) "Mylyn WikiText Textile UI" [Resolved]
        org.eclipse.mylyn.wikitext.tracwiki.core (1.4.0.v20110316-0100) "Mylyn WikiText TracWiki" [Resolved]
        org.eclipse.mylyn.wikitext.tracwiki.ui (1.4.0.v20110316-0100) "Mylyn WikiText TracWiki UI" [Resolved]
        org.eclipse.mylyn.wikitext.twiki.core (1.4.0.v20110316-0100) "Mylyn WikiText Twiki" [Resolved]
        org.eclipse.mylyn.wikitext.twiki.ui (1.4.0.v20110316-0100) "Mylyn WikiText Twiki UI" [Resolved]
        org.eclipse.mylyn.wikitext.ui (1.4.0.v20110316-0100) "Mylyn WikiText UI" [Active]
        org.eclipse.osgi (3.6.2.R36x_v20110210) "OSGi System Bundle" [Active]
        org.eclipse.osgi.services (3.2.100.v20100503) "OSGi Release 4.2.0 Services" [Resolved]
        org.eclipse.osgi.util (3.2.100.v20100503) "OSGi Release 4.2.0 Utility Classes" [Resolved]
        org.eclipse.pde (3.6.1.v201102101200) "PDE" [Resolved]
        org.eclipse.pde.api.tools (1.0.202.v20100820_r361) "API Tools" [Active]
        org.eclipse.pde.api.tools.ui (1.0.201.v20100820_r361) "API Tools UI" [Active]
        org.eclipse.pde.build (3.6.2.R36x_20110203) "Plug-in Development Environment Build Support" [Starting]
        org.eclipse.pde.core (3.6.2.v20110210_r362) "PDE Core" [Active]
        org.eclipse.pde.doc.user (3.6.2.v20101118_r362) "PDE User Guide" [Resolved]
        org.eclipse.pde.ds.core (1.0.100.v20100601) "PDE DS Core" [Starting]
        org.eclipse.pde.ds.ui (1.0.100.v20100601) "PDE DS UI" [Starting]
        org.eclipse.pde.junit.runtime (3.4.100.v20100601) "PDE JUnit Runtime Support" [Resolved]
        org.eclipse.pde.launching (3.6.0.v20100601) "PDE Launching Support" [Active]
        org.eclipse.pde.runtime (3.4.200.v20100601) "PDE Runtime" [Starting]
        org.eclipse.pde.ua.core (1.0.100.v20100504) "PDE UA Core" [Starting]
        org.eclipse.pde.ua.ui (1.0.100.v20100504) "PDE UA UI" [Starting]
        org.eclipse.pde.ui (3.6.1.v20110210_r362) "PDE UI" [Active]
        org.eclipse.pde.ui.templates (3.4.200.v20100601) "PDE Templates" [Starting]
        org.eclipse.persistence.antlr (2.1.2.v20101206-r8635) "EclipseLink ANTLR" [Resolved]
        org.eclipse.persistence.asm (2.1.2.v20101206-r8635) "EclipseLink ASM" [Resolved]
        org.eclipse.persistence.core (2.1.2.v20101206-r8635) "EclipseLink Core" [Resolved]
        org.eclipse.persistence.jpa (2.1.2.v20101206-r8635) "EclipseLink JPA" [Resolved]
        org.eclipse.persistence.jpa.equinox (2.1.2.v20101206-r8635) "EclipseLink Dynamic Weaving Fragment for Equinox" [Resolved]
        org.eclipse.persistence.jpa.equinox.weaving (2.1.2.v20101206-r8635) "Dynamic Weaving Fragment for Equinox" [Resolved]
        org.eclipse.persistence.jpa.osgi (2.1.2.v20101206-r8635) "EclipseLink OSGi Deployment Fragment (deprectated, non Gemini)" [Resolved]
        org.eclipse.persistence.moxy (2.1.2.v20101206-r8635) "EclipseLink MOXy" [Resolved]
        org.eclipse.persistence.oracle (2.1.2.v20101206-r8635) "EclipseLink Oracle Extensions" [Resolved]
        org.eclipse.persistence.sdo (2.1.2.v20101206-r8635) "EclipseLink SDO" [Resolved]
        org.eclipse.platform (3.6.2.v201102101200) "Eclipse Platform" [Resolved]
        org.eclipse.platform.doc.user (3.6.2.r362_v20101117-0800) "Eclipse Workbench User Guide" [Resolved]
        org.eclipse.rcp (3.6.0.v201102101200) "Eclipse RCP" [Starting]
        org.eclipse.rse (3.2.2.R32x_v201102011435) "Remote System Explorer End-User Runtime" [Resolved]
        org.eclipse.rse.connectorservice.dstore (3.1.100.v201005281600) "RSE DStore Connector Service" [Starting]
        org.eclipse.rse.connectorservice.local (2.1.100.v200905272300) "RSE Local Connector Service" [Starting]
        org.eclipse.rse.connectorservice.ssh (2.1.100.v200905272300) "RSE SSH Connector Service" [Starting]
        org.eclipse.rse.connectorservice.telnet (1.2.1.v200908051630) "RSE Telnet Connector Service" [Starting]
        org.eclipse.rse.core (3.1.102.R32x_v201102011435) "RSE Core" [Starting]
        org.eclipse.rse.doc.user (3.2.2.R32x_v201102011435) "RSE User Guide" [Resolved]
        org.eclipse.rse.dstore.security (3.0.200.v201003010830) "RSE DStore SSL Support" [Starting]
        org.eclipse.rse.efs (2.1.200.v201005262000) "RSE Eclipse Filesystem (EFS) Provider" [Starting]
        org.eclipse.rse.efs.ui (2.1.200.v201003010830) "RSE Eclipse Filesystem (EFS) Provider UI Support" [Resolved]
        org.eclipse.rse.files.ui (3.1.102.R32x_v201102011435) "RSE Files UI" [Starting]
        org.eclipse.rse.importexport (1.2.101.v201008191400) "RSE Import/Export" [Starting]
        org.eclipse.rse.processes.ui (3.0.200.v201003010830) "RSE Processes UI" [Starting]
        org.eclipse.rse.services (3.2.2.R32x_v201102011435) "RSE Services Framework" [Starting]
        org.eclipse.rse.services.dstore (3.1.102.R32x_v201102011435) "RSE DStore Services" [Starting]
        org.eclipse.rse.services.files.ftp (3.0.200.v201004072040) "RSE FTP Service" [Starting]
        org.eclipse.rse.services.local (2.1.202.R32x_v201102011435) "RSE Local Services" [Starting]
        org.eclipse.rse.services.ssh (3.0.1.v200909160005) "RSE SSH Services" [Starting]
        org.eclipse.rse.services.telnet (2.0.0.v200905272300) "RSE Telnet Service" [Starting]
        org.eclipse.rse.shells.ui (3.0.200.v201006041352) "RSE Shells UI" [Starting]
        org.eclipse.rse.subsystems.files.core (3.2.1.v201008191400) "RSE Files Core" [Starting]
        org.eclipse.rse.subsystems.files.dstore (2.1.102.R32x_v201102011435) "RSE DStore Files" [Starting]
        org.eclipse.rse.subsystems.files.ftp (2.1.100.v200905272300) "RSE FTP Files" [Starting]
        org.eclipse.rse.subsystems.files.local (2.1.101.v200907301400) "RSE Local Files" [Starting]
        org.eclipse.rse.subsystems.files.ssh (2.1.100.v200905272300) "RSE SSH Files" [Starting]
        org.eclipse.rse.subsystems.processes.core (3.1.100.v201003010830) "RSE Processes Core" [Starting]
        org.eclipse.rse.subsystems.processes.dstore (2.1.100.v200905272300) "RSE DStore Processes" [Starting]
        org.eclipse.rse.subsystems.processes.local (2.1.100.v200905272300) "RSE Local Processes" [Starting]
        org.eclipse.rse.subsystems.processes.shell.linux (1.1.100.v200905272300) "RSE Linux Shell Processes" [Starting]
        org.eclipse.rse.subsystems.shells.core (3.1.100.v201003010830) "RSE Shells Core" [Starting]
        org.eclipse.rse.subsystems.shells.dstore (2.1.201.v201008191400) "RSE DStore Shells" [Starting]
        org.eclipse.rse.subsystems.shells.local (2.1.100.v200905272300) "RSE Local Shells" [Starting]
        org.eclipse.rse.subsystems.shells.ssh (2.1.100.v200905272300) "RSE SSH Shells" [Starting]
        org.eclipse.rse.subsystems.shells.telnet (1.2.0.v200905272300) "RSE Telnet Shells" [Starting]
        org.eclipse.rse.subsystems.terminals.core (1.0.100.v201006041352) "RSE Terminals Core" [Resolved]
        org.eclipse.rse.subsystems.terminals.ssh (1.0.1.v200908051630) "RSE SSH Terminals" [Starting]
        org.eclipse.rse.terminals.ui (1.0.100.v201006041352) "RSE Terminals UI" [Starting]
        org.eclipse.rse.ui (3.1.102.R32x_v201102011435) "RSE UI" [Starting]
        org.eclipse.rse.useractions (1.1.100.v200905272300) "Remote System Explorer User Actions" [Starting]
        org.eclipse.search (3.6.0.v20100520-0800) "Search Support" [Active]
        org.eclipse.swt (3.6.2.v3659c) "Standard Widget Toolkit" [Resolved]
        org.eclipse.swt.gtk.linux.x86 (3.6.2.v3659b) "Standard Widget Toolkit for GTK 2.0" [Resolved]
        org.eclipse.team.core (3.5.101.R36x_v20110203-1036) "Team Support Core" [Active]
        org.eclipse.team.cvs.core (3.3.301.R36x_v20110119-0815) "CVS Team Provider Core" [Active]
        org.eclipse.team.cvs.ssh2 (3.2.300.I20100526-0800) "CVS SSH2" [Starting]
        org.eclipse.team.cvs.ui (3.3.302.R36x_v20110203-1036) "CVS Team Provider UI" [Active]
        org.eclipse.team.svn (0.7.9.I20110318-1700) "Subversive SVN Team Provider (Incubation)" [Resolved]
        org.eclipse.team.svn.core (0.7.9.I20110523-1700) "Subversive SVN Team Provider Core Plug-in (Incubation)" [Active]
        org.eclipse.team.svn.help (0.7.9.I20110318-1700) "Subversive SVN Team Provider User Guide Plug-in (Incubation)" [Resolved]
        org.eclipse.team.svn.mylyn (0.7.9.I20110318-1700) "Subversive Integration for the Mylyn Project (Incubation)" [Active]
        org.eclipse.team.svn.resource.ignore.rules.jdt (0.7.9.I20101203-1700) "Subversive JDT Ignore Extensions (Incubation)" [Resolved]
        org.eclipse.team.svn.ui (0.7.9.I20110523-1700) "Subversive SVN Team Provider UI Plug-in (Incubation)" [Active]
        org.eclipse.team.ui (3.5.102.R36x_v20110203-1036) "Team Support UI" [Active]
        org.eclipse.text (3.5.0.v20100601-1300) "Text" [Resolved]
        org.eclipse.tm.terminal (3.0.102.R32x_v201102011435) "Target Management Terminal Widget" [Starting]
        org.eclipse.tm.terminal.ssh (2.0.200.v201005271030) "Target Management Terminal SSH Connector" [Starting]
        org.eclipse.tm.terminal.telnet (2.0.101.v200909160005) "Target Management Terminal Telnet Connector" [Resolved]
        org.eclipse.tm.terminal.view (2.1.2.R32x_v201102011435) "Target Management Terminal View" [Starting]
        org.eclipse.ui (3.6.2.M20110203-1100) "Eclipse UI" [Active]
        org.eclipse.ui.browser (3.3.1.r36_20101216) "Browser Support" [Active]
        org.eclipse.ui.cheatsheets (3.4.0.v20100427) "Cheat Sheets" [Active]
        org.eclipse.ui.console (3.5.0.v20100526) "Console" [Active]
        org.eclipse.ui.editors (3.6.1.r361_v20100825-0800) "Default Text Editor" [Active]
        org.eclipse.ui.externaltools (3.2.0.v20100427) "External Tools" [Starting]
        org.eclipse.ui.forms (3.5.2.r36_v20100702) "Eclipse Forms" [Active]
        org.eclipse.ui.ide (3.6.2.M20101201-0800) "Eclipse IDE UI" [Active]
        org.eclipse.ui.ide.application (1.0.201.M20100707-0800) "Eclipse IDE UI Application" [Resolved]
        org.eclipse.ui.intro (3.4.0.v20100427) "Welcome Framework" [Starting]
        org.eclipse.ui.intro.universal (3.2.402.r36_v20100702) "Universal Welcome" [Starting]
        org.eclipse.ui.navigator (3.5.0.I20100601-0800) "Common Navigator View" [Active]
        org.eclipse.ui.navigator.resources (3.4.202.M20101124-0800) "Navigator Workbench Components" [Active]
        org.eclipse.ui.net (1.2.100.I20100505-1245) "Internet Connection Management UI" [Active]
        org.eclipse.ui.presentations.r21 (3.2.200.I20100517-1500) "R21 Presentation Plug-in" [Starting]
        org.eclipse.ui.views (3.5.1.M20110202-0800) "Views" [Active]
        org.eclipse.ui.views.log (1.0.100.v20110210_r362) "Log View" [Active]
        org.eclipse.ui.views.properties.tabbed (3.5.100.I20100509-0800) "Tabbed Properties View" [Active]
        org.eclipse.ui.workbench (3.6.2.M20110210-1200) "Workbench" [Active]
        org.eclipse.ui.workbench.compatibility (3.2.100.I20100511-0800) "Workbench Compatibility" [Resolved]
        org.eclipse.ui.workbench.texteditor (3.6.1.r361_v20100714-0800) "Text Editor Framework" [Active]
        org.eclipse.update.configurator (3.3.100.v20100512) "Install/Update Configurator" [Active]
        org.eclipse.update.core (3.2.402.R36x_v20100629) "Install/Update Core" [Active]
        org.eclipse.update.core.linux (3.2.200.v20100512) "fragmentNameLinux" [Resolved]
        org.eclipse.update.scheduler (3.2.300.v20100512) "Automatic Updates Scheduler" [Active]
        org.eclipse.update.ui (3.2.300.v20100512) "Install/Update UI" [Starting]
        org.eclipse.wst.command.env (1.0.409.v201004211805) "Environment Command Framework (headless)" [Active]
        org.eclipse.wst.command.env.core (1.0.205.v201004211805) "Environment Command Framework (core)" [Resolved]
        org.eclipse.wst.command.env.doc.user (1.5.300.v201005192225) "Web services Axis Ant task documentation" [Starting]
        org.eclipse.wst.command.env.infopop (1.0.100.v200805301544) "Web services UI" [Starting]
        org.eclipse.wst.command.env.ui (1.1.3.v201004211805) "Environment Command Framework (GUI)" [Starting]
        org.eclipse.wst.common.core (1.2.0.v200908252030) "WST Common Core Plug-in" [Active]
        org.eclipse.wst.common.emf (1.2.3.v201012100400) "EMF Utilities" [Active]
        org.eclipse.wst.common.emfworkbench.integration (1.2.3.v201012020600) "EMF Workbench Edit Plug-in" [Active]
        org.eclipse.wst.common.environment (1.0.400.v200912181832) "Environment Plug-in" [Starting]
        org.eclipse.wst.common.frameworks (1.2.0.v201003040800) "Common Frameworks" [Active]
        org.eclipse.wst.common.frameworks.ui (1.2.0.v201004080500) "WTP UI Plug-in" [Active]
        org.eclipse.wst.common.infopop (1.0.300.v201004280700) "Common WST infopops" [Starting]
        org.eclipse.wst.common.modulecore (1.2.5.v201101270100) "Modulecore Plug-in" [Active]
        org.eclipse.wst.common.modulecore.ui (1.0.4.v201101101700) "Modulecore UI Plug-in" [Starting]
        org.eclipse.wst.common.project.facet.core (1.4.102.v201008170019) "Eclipse Faceted Project Framework" [Active]
        org.eclipse.wst.common.project.facet.ui (1.4.103.v201101271715) "Eclipse Faceted Project Framework UI" [Starting]
        org.eclipse.wst.common.snippets (1.2.2.v201101130441) "Snippets View" [Starting]
        org.eclipse.wst.common.ui (1.1.500.v200911190730) "Eclipse Base UI extensions" [Starting]
        org.eclipse.wst.common.uriresolver (1.1.401.v201004280700) "Common URI Resolver Framework" [Active]
        org.eclipse.wst.css.core (1.1.402.v201102031915) "Structured Source CSS Model" [Active]
        org.eclipse.wst.css.ui (1.0.502.v201101122002) "SSE CSS Source Editor" [Starting]
        org.eclipse.wst.doc.user (1.2.0.v200806052254) "Master User Doc TOC" [Starting]
        org.eclipse.wst.dtd.core (1.1.401.v201101122255) "Structured Source DTD Core" [Active]
        org.eclipse.wst.dtd.ui (1.0.500.v201004290328) "SSE DTD Source Editor" [Active]
        org.eclipse.wst.dtd.ui.infopop (1.0.300.v200805140200) "DTD Editor infopops" [Resolved]
        org.eclipse.wst.dtdeditor.doc.user (1.0.600.v201005192212) "DTD Editor documentation" [Resolved]
        org.eclipse.wst.html.core (1.1.404.v201101190004) "Structured Source HTML Model" [Active]
        org.eclipse.wst.html.ui (1.0.504.v201101122108) "HTML UI Source Editor" [Active]
        org.eclipse.wst.html.ui.infopop (1.0.200.v201004150328) "HTML editor infopops" [Resolved]
        org.eclipse.wst.internet.cache (1.0.400.v201004280700) "Cache URI Resolver Plug-in" [Active]
        org.eclipse.wst.internet.monitor.core (1.0.404.v20090609) "Monitor" [Starting]
        org.eclipse.wst.internet.monitor.ui (1.0.405.v20100309) "TCP/IP Monitor" [Starting]
        org.eclipse.wst.jsdt.core (1.1.4.v201102102045) "JavaScript Development Tools Core" [Active]
        org.eclipse.wst.jsdt.debug.core (1.0.3.v201011040143) "JavaScript Debug Core" [Active]
        org.eclipse.wst.jsdt.debug.rhino (1.0.1.v201008170101) "Rhino JavaScript Debug" [Starting]
        org.eclipse.wst.jsdt.debug.rhino.debugger (1.0.1.v201008170101) "Rhino Debugger" [Resolved]
        org.eclipse.wst.jsdt.debug.ui (1.0.3.v201011040143) "JavaScript Debug UI" [Active]
        org.eclipse.wst.jsdt.doc (1.0.301.v201007150153) "JSDT Doc Plugin" [Resolved]
        org.eclipse.wst.jsdt.manipulation (1.0.200.v201004150600) "JavaScript Code Manipulation Functionality" [Active]
        org.eclipse.wst.jsdt.support.firefox (1.0.300.v201004150600) "JSDT support for Mozilla FireFox" [Starting]
        org.eclipse.wst.jsdt.support.ie (1.0.300.v201004150600) "JSDT support for Microsoft Internet Explorer" [Resolved]
        org.eclipse.wst.jsdt.ui (1.1.4.v201102160540) "Eclipse JavaScript Development Tools" [Active]
        org.eclipse.wst.jsdt.web.core (1.0.304.v201102160550) "JSDT Web Support Core" [Starting]
        org.eclipse.wst.jsdt.web.support.jsp (1.0.303.v201012160047) "JSDT support for JSP Plug-in" [Starting]
        org.eclipse.wst.jsdt.web.ui (1.0.304.v201012160349) "JSDT Web Support UI" [Starting]
        org.eclipse.wst.server.core (1.1.206.v20110110) "Server Core" [Active]
        org.eclipse.wst.server.discovery (1.0.101.v20100707) "Plug-in Discovery Plug-in" [Starting]
        org.eclipse.wst.server.http.core (1.0.200.v20090429) "HTTP Server Support" [Starting]
        org.eclipse.wst.server.http.ui (1.0.200.v20090113) "HTTP Server UI Support" [Starting]
        org.eclipse.wst.server.preview (1.1.100.v20091208) "Preview Server Support" [Starting]
        org.eclipse.wst.server.preview.adapter (1.1.0.v20090311b) "HTTP Preview Support" [Starting]
        org.eclipse.wst.server.ui (1.1.207.v20110119) "Server UI" [Active]
        org.eclipse.wst.server.ui.doc.user (1.1.300.v201005192125) "Server Tools documentation for Web Standard Tools" [Starting]
        org.eclipse.wst.server.ui.infopop (1.1.100.v201005192130) "Server Tools infopops for Web Standard Tools" [Resolved]
        org.eclipse.wst.sse.core (1.1.504.v201102160550) "Structured Source Model" [Active]
        org.eclipse.wst.sse.doc.user (1.1.100.v201005192212) "Structured text editor and snippets documentation" [Resolved]
        org.eclipse.wst.sse.ui (1.2.3.v201102102045) "Structured Source Editor" [Active]
        org.eclipse.wst.sse.ui.infopop (1.0.300.v201004150328) "SSE infopops" [Resolved]
        org.eclipse.wst.standard.schemas (1.0.300.v201004110600) "Standard Schemas and DTDs" [Resolved]
        org.eclipse.wst.validation (1.2.201.v201101270100) "Validation Framework" [Active]
        org.eclipse.wst.validation.infopop (1.0.300.v200806041506) "WST validation infopop plug-in" [Resolved]
        org.eclipse.wst.validation.ui (1.2.204.v201004150700) "Validation Framework UI" [Starting]
        org.eclipse.wst.web (1.1.402.v201012160000) "Simple Web Plug-in" [Active]
        org.eclipse.wst.web.ui (1.1.400.v201004141630) "Eclipse Web Developer Tools" [Starting]
        org.eclipse.wst.web.ui.infopop (1.0.300.v200805140415) "Static Web infopop" [Starting]
        org.eclipse.wst.webtools.doc.user (1.0.500.v201005192212) "Web tools documentation" [Starting]
        org.eclipse.wst.ws (1.1.203.v201004211805) "Web Services" [Active]
        org.eclipse.wst.ws.explorer (1.0.507.v201004220342) "Web Services Explorer" [Starting]
        org.eclipse.wst.ws.infopop (1.0.300.v200805140230) "Web Services UI" [Starting]
        org.eclipse.wst.ws.parser (1.0.403.v201004211805) "Web Services Description Parser" [Starting]
        org.eclipse.wst.ws.service.policy (1.0.204.v201011011834) "Service Policy - Core" [Active]
        org.eclipse.wst.ws.service.policy.ui (1.0.202.v201004211732) "Service Policy - UI" [Active]
        org.eclipse.wst.ws.ui (1.1.200.v201004211805) "Web Services UI" [Starting]
        org.eclipse.wst.wsdl (1.2.104.v201012082239) "WSDL Model" [Starting]
        org.eclipse.wst.wsdl.ui (1.2.304.v201012071645) "WSDL UI" [Starting]
        org.eclipse.wst.wsdl.ui.doc.user (1.0.700.v201007141653) "WSDL Editor Documentation" [Starting]
        org.eclipse.wst.wsdl.validation (1.1.501.v201004201506) "WSDL Validator" [Active]
        org.eclipse.wst.wsi (1.0.400.v201004220210) "WSI Conformance Tools" [Active]
        org.eclipse.wst.wsi.ui (1.0.501.v201004201506) "Soap Monitor" [Starting]
        org.eclipse.wst.wsi.ui.doc.user (1.0.600.v201007141654) "WS-I Validation Documentation" [Resolved]
        org.eclipse.wst.xml.core (1.1.503.v201102102045) "Structured Source XML Model" [Active]
        org.eclipse.wst.xml.ui (1.1.103.v201101122108) "Eclipse XML Editors and Tools" [Active]
        org.eclipse.wst.xml.ui.infopop (1.0.400.v201004292007) "XML infopops" [Resolved]
        org.eclipse.wst.xml.xpath.core (1.1.1.v201007022358) "XPath Core" [Starting]
        org.eclipse.wst.xml.xpath.ui (1.1.2.v201101212242) "XPath UI" [Starting]
        org.eclipse.wst.xml.xpath2 (1.1.0.v200910101444) "Eclipse XPath 2 Developers Tools" [Resolved]
        org.eclipse.wst.xml.xpath2.processor (1.1.4.v201101212357) "PsychoPath XPath 2.0 Processor" [Starting]
        org.eclipse.wst.xml.xpath2.processor.doc.user (1.0.0.v201005240426) "XPath 2.0 (PsychoPath) User Documentation" [Resolved]
        org.eclipse.wst.xmleditor.doc.user (1.0.700.v201005192212) "XML editor" [Resolved]
        org.eclipse.wst.xsd.core (1.1.503.v201011121919) "XSD Core Plugin" [Active]
        org.eclipse.wst.xsd.ui (1.2.304.v201101251958) "XML Schema Editor" [Starting]
        org.eclipse.wst.xsdeditor.doc.user (1.0.800.v201005192212) "XML schema editor" [Resolved]
        org.eclipse.wst.xsl (1.0.0.v200905250058) "Eclipse XSL Developer Tools" [Resolved]
        org.eclipse.wst.xsl.core (1.1.0.v201004290328) "XSL Core" [Active]
        org.eclipse.wst.xsl.debug.ui (1.0.101.v201102111830) "XSL Debugger UI" [Active]
        org.eclipse.wst.xsl.doc (1.0.100.v201004292007) "XSL User Documentation (Incubating)" [Resolved]
        org.eclipse.wst.xsl.exslt.core (1.0.0.v201005240426) "EXSLT UI Extensions" [Active]
        org.eclipse.wst.xsl.exslt.ui (1.0.0.v201006012005) "EXSLT Core Extensions" [Starting]
        org.eclipse.wst.xsl.jaxp.debug (1.0.100.v201004290328) "XSL JAXP Debugger" [Resolved]
        org.eclipse.wst.xsl.jaxp.debug.ui (1.0.100.v201004290328) "XSL JAXP Debug UI" [Starting]
        org.eclipse.wst.xsl.jaxp.launching (1.0.100.v201004290328) "XSL JAXP Launching" [Starting]
        org.eclipse.wst.xsl.launching (1.0.100.v201004290328) "XSL Transform Launching" [Starting]
        org.eclipse.wst.xsl.saxon (1.0.100.v201004290328) "XSL Saxon Support" [Resolved]
        org.eclipse.wst.xsl.ui (1.1.1.v201009091745) "XSL Editor and Validation" [Active]
        org.eclipse.wst.xsl.xalan (1.0.1.v201004290328) "XSL Xalan Support" [Resolved]
        org.eclipse.xsd (2.6.0.v20100914-1218) "XSD Model" [Active]
        org.eclipse.xsd.edit (2.6.0.v20100914-1218) "XSD Edit" [Starting]
        org.eclipse.zest.core (1.2.0.v20101209-2020) "Graphical Editing Framework Zest Core" [Resolved]
        org.eclipse.zest.layouts (1.1.0.v20101209-2020) "Graphical Editing Framework Zest Layouts" [Resolved]
        org.h2 (1.1.117.v20091003-1000) "H2 Database Engine" [Resolved]
        org.hamcrest.core (1.1.0.v20090501071000) "Hamcrest Core Library of Matchers" [Starting]
        org.jdom (1.0.0.v201005080400) "JDOM" [Resolved]
        org.junit (3.8.2.v3_8_2_v20100427-1100) "JUnit Testing Framework" [Resolved]
        org.junit (4.8.1.v4_8_1_v20100427-1100) "JUnit Testing Framework" [Resolved]
        org.junit4 (4.8.1.v20100525) "JUnit Testing Framework Version 4" [Resolved]
        org.maven.ide.eclipse (0.12.1.20110112-1712) "Maven Integration for Eclipse" [Active]
        org.maven.ide.eclipse.ajdt (0.10.0.20100209-0800) "Maven Integration for Eclipse AJDT" [Resolved]
        org.maven.ide.eclipse.archetype_common (0.12.1.20110112-1712) "Maven Archetype Common Bundle" [Resolved]
        org.maven.ide.eclipse.dependency_tree (0.12.1.20110112-1712) "Maven Dependency Tree Bundle" [Resolved]
        org.maven.ide.eclipse.editor (0.12.1.20110112-1712) "Maven Integration for Eclipse (Editors)" [Active]
        org.maven.ide.eclipse.editor.xml (0.12.1.20110112-1712) "Maven POM XML Editor" [Active]
        org.maven.ide.eclipse.jdt (0.12.1.20110112-1712) "Maven Integration for Eclipse JDT" [Active]
        org.maven.ide.eclipse.launching (0.12.1.20110112-1712) "Maven Integration for Eclipse Launching" [Active]
        org.maven.ide.eclipse.maven_embedder (0.12.1.20110112-1712) "Embedded Maven Runtime Bundle" [Resolved]
        org.maven.ide.eclipse.maven_model_edit (0.12.1.20110112-1712) "Maven Project Model Edit Bundle" [Active]
        org.maven.ide.eclipse.nexus_indexer (0.12.1.20110112-1712) "Nexus Indexer Bundle" [Resolved]
        org.maven.ide.eclipse.plexus.annotations (0.12.0.20101103-1500) "Plexus Metadata Generation" [Resolved]
        org.maven.ide.eclipse.pr (0.12.1.20110112-1712) "Maven Problem Reporting" [Resolved]
        org.maven.ide.eclipse.refactoring (0.12.1.20110112-1712) "Maven Integration for Eclipse Refactoring" [Active]
        org.maven.ide.eclipse.temporary.mojos (0.12.0.20101103-1500) "Collection of project configurators (temporary)" [Resolved]
        org.maven.ide.eclipse.wtp (0.11.1.20101108-1810) "Maven Integration for Eclipse WTP" [Active]
        org.mortbay.jetty.server (6.1.23.v201004211559) "Jetty Server" [Resolved]
        org.mortbay.jetty.util (6.1.23.v201004211559) "Jetty Utilities" [Resolved]
        org.mozilla.javascript (1.7.2.v201005080400) "Mozilla Rhino" [Resolved]
        org.objectweb.asm (3.2.0.v200909071300) "ASM" [Resolved]
        org.polarion.eclipse.team.svn.connector (2.2.2.I20110318-1700) "Subversive SVN Connectors" [Resolved]
        org.polarion.eclipse.team.svn.connector.javahl16 (2.2.2.I20110523-1700) "Subversive SVN 1.6 JavaHL Connector" [Active]
        org.polarion.eclipse.team.svn.connector.svnkit16 (2.2.2.I20110523-1700) "Subversive SVN 1.6 SVN Kit Connector" [Active]
        org.sat4j.core (2.2.0.v20100429) "SAT4J Core" [Resolved]
        org.sat4j.pb (2.2.0.v20100429) "SAT4J Pseudo" [Resolved]
        org.sonatype.tycho.m2e (0.4.3.20101103-1630) "Tycho Project Configurators" [Active]
        org.springframework.aop (3.0.5.RELEASE) "Spring AOP" [Resolved]
        org.springframework.asm (3.0.5.RELEASE) "Spring ASM" [Resolved]
        org.springframework.batch.core (2.1.0.RELEASE) "Spring Batch Core" [Resolved]
        org.springframework.batch.infrastructure (2.1.0.RELEASE) "Spring Batch Infrastructure" [Resolved]
        org.springframework.beans (3.0.5.RELEASE) "Spring Beans" [Resolved]
        org.springframework.binding (2.0.7.A) "Spring Binding" [Resolved]
        org.springframework.context (3.0.5.RELEASE) "Spring Context" [Resolved]
        org.springframework.context.support (3.0.5.RELEASE) "Spring Context Support" [Resolved]
        org.springframework.core (3.0.5.RELEASE) "Spring Core" [Resolved]
        org.springframework.expression (3.0.5.RELEASE) "Spring Expression Language" [Resolved]
        org.springframework.faces (2.0.7.A) "Spring Faces" [Resolved]
        org.springframework.ide.eclipse (2.6.0.201103160035-RELEASE) "Spring IDE" [Resolved]
        org.springframework.ide.eclipse.ajdt.ui.visualiser (2.6.0.201103160035-RELEASE) "Spring IDE AOP Visualiser UI" [Starting]
        org.springframework.ide.eclipse.ajdt.ui.xref (2.6.0.201103160035-RELEASE) "Spring IDE AOP Xref UI" [Starting]
        org.springframework.ide.eclipse.aop.core (2.6.0.201103160035-RELEASE) "Spring IDE AOP Core" [Active]
        org.springframework.ide.eclipse.aop.mylyn (2.6.0.201103160035-RELEASE) "Spring IDE AOP Mylyn Integration" [Starting]
        org.springframework.ide.eclipse.aop.ui (2.6.0.201103160035-RELEASE) "Spring IDE AOP UI" [Active]
        org.springframework.ide.eclipse.aop.ui.matcher (2.6.0.201103160035-RELEASE) "Spring IDE AOP Pointcut Matcher" [Starting]
        org.springframework.ide.eclipse.batch (2.6.0.201103160035-RELEASE) "Spring IDE Support for Spring Batch" [Active]
        org.springframework.ide.eclipse.beans.core (2.6.0.201104111100-PATCH) "Spring IDE Beans Core" [Active]
        org.springframework.ide.eclipse.beans.core.autowire (2.6.0.201103160035-RELEASE) "Spring IDE Autowiring Support (Core)" [Active]
        org.springframework.ide.eclipse.beans.core.metadata (2.6.0.201103160035-RELEASE) "Spring IDE Metadata Support (Core)" [Active]
        org.springframework.ide.eclipse.beans.mylyn (2.6.0.201103160035-RELEASE) "Spring IDE Beans Mylyn Integration" [Active]
        org.springframework.ide.eclipse.beans.ui (2.6.0.201103160035-RELEASE) "Spring IDE Beans UI" [Active]
        org.springframework.ide.eclipse.beans.ui.autowire (2.6.0.201103160035-RELEASE) "Spring IDE Autowiring Support (UI)" [Starting]
        org.springframework.ide.eclipse.beans.ui.editor (2.6.0.201103160035-RELEASE) "Spring IDE Beans Config Editor" [Active]
        org.springframework.ide.eclipse.beans.ui.graph (2.6.0.201103160035-RELEASE) "Spring IDE Bean Dependency Graph" [Active]
        org.springframework.ide.eclipse.beans.ui.refactoring (2.6.0.201103160035-RELEASE) "Spring IDE Refactoring Support" [Active]
        org.springframework.ide.eclipse.beans.ui.search (2.6.0.201103160035-RELEASE) "Spring IDE Beans UI Search" [Starting]
        org.springframework.ide.eclipse.core (2.6.0.201104111100-PATCH) "Spring IDE Core" [Active]
        org.springframework.ide.eclipse.doc (2.6.0.201103160035-RELEASE) "Spring Framework Reference Documentations" [Resolved]
        org.springframework.ide.eclipse.integration (2.6.0.201103160035-RELEASE) "Spring IDE Support for Spring Integration" [Active]
        org.springframework.ide.eclipse.mylyn (2.6.0.201103160035-RELEASE) "Spring IDE Mylyn Integration" [Starting]
        org.springframework.ide.eclipse.osgi (2.6.0.201103160035-RELEASE) "Spring IDE Support for Spring Dynamic Modules for OSGi(tm) Service Platforms" [Starting]
        org.springframework.ide.eclipse.osgi.targetdefinition (2.6.0.201103160035-RELEASE) "Spring Dynamic Modules for OSGi(tm) Service Platforms Target Definition" [Active]
        org.springframework.ide.eclipse.security (2.6.0.201103160035-RELEASE) "Spring IDE Core Support for Spring Security" [Active]
        org.springframework.ide.eclipse.uaa (2.6.0.201104111100-PATCH) "Spring IDE Spring User Agent Analysis Integration" [Active]
        org.springframework.ide.eclipse.ui (2.6.0.201103160035-RELEASE) "Spring IDE UI" [Active]
        org.springframework.ide.eclipse.webflow.core (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow Core" [Active]
        org.springframework.ide.eclipse.webflow.mylyn (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow Mylyn Integration" [Active]
        org.springframework.ide.eclipse.webflow.ui (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow UI" [Active]
        org.springframework.ide.eclipse.webflow.ui.editor (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow Config Editor" [Active]
        org.springframework.ide.eclipse.webflow.ui.graph (2.6.0.201103160035-RELEASE) "Spring IDE Web Flow UI Editor" [Starting]
        org.springframework.jdbc (3.0.5.RELEASE) "Spring JDBC" [Resolved]
        org.springframework.jms (3.0.5.RELEASE) "Spring JMS" [Resolved]
        org.springframework.js (2.0.7.A) "Spring JS" [Resolved]
        org.springframework.orm (3.0.5.RELEASE) "Spring ORM" [Resolved]
        org.springframework.osgi.core (2.0.0.M2-SNAPSHOT) "spring-osgi-core" [Resolved]
        org.springframework.osgi.io (2.0.0.M2-SNAPSHOT) "spring-osgi-io" [Resolved]
        org.springframework.oxm (3.0.5.RELEASE) "Spring Object/XML Mapping" [Resolved]
        org.springframework.security.config (3.0.2.RELEASE) "Spring Security Namespace Configuration" [Resolved]
        org.springframework.security.core (3.0.2.RELEASE) "Spring Security Core" [Resolved]
        org.springframework.security.web (3.0.2.RELEASE) "Spring Security Web" [Resolved]
        org.springframework.transaction (3.0.5.RELEASE) "Spring Transaction" [Resolved]
        org.springframework.web (3.0.5.RELEASE) "Spring Web" [Resolved]
        org.springframework.web.servlet (3.0.5.RELEASE) "Spring Web Servlet" [Resolved]
        org.springframework.webflow (2.0.7.A) "Spring Web Flow" [Resolved]
        org.springframework.ws (1.5.8.A) "Spring Web Services Core" [Resolved]
        org.springframework.xml (1.5.8.A) "Spring XML" [Resolved]
        org.uddi4j (2.0.5.v200805270300) "UDDI4J" [Resolved]
        org.zeroturnaround.eclipse (1.4.1.201106011211) "JRebel Eclipse Plug-in" [Active]
        org.zeroturnaround.eclipse.debug (1.4.0.201105311642) "JRebel Eclipse Debugger Plug-in" [Active]
        org.zeroturnaround.eclipse.embedder (4.0.0.201105311642) "Embedded JRebel for Eclipse" [Active]
        org.zeroturnaround.eclipse.wtp (1.4.0.201105311642) "JRebel WTP Integration Plug-in" [Starting]

Attachments: Text File greclipe-stacks.txt     Text File GRECLIPSE-1074-updatedeclipseerror.txt     Text File GRECLIPSE-1074-updateenvironment.txt    
Issue Links:
Related
is related to GRECLIPSE-1181 out of space in CodeCache for adapters Resolved
Number of attachments : 3

 Description   

I am having trouble figuring out exactly what causes this, but sometimes when I open the Groovy Editor I get the error below. It seems to be related to when I receive an update for Groovy compiler it automatically switches me to 1.8 compiler. I then switch back to 1.7 and afterwards opening a Spock test causes this error. Again, I am not really certain of all the details, but am hoping this might be enough for someone with more knowledge to figure this out. If not, I can attempt to isolate the problem further.

Closing and reopening the project does not appear to help. Cleaning the project also appears to have no impact. Restarting eclipse temporarily fixes it.

Unable to create editor ID org.codehaus.groovy.eclipse.editor.GroovyEditor: Editor could not be initialized.

java.lang.VerifyError: (class: org/codehaus/groovy/runtime/ArrayUtil, method: <clinit> signature: ()V) Illegal type in constant pool
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
	at org.codehaus.groovy.eclipse.editor.highlighting.HighlightingExtenderRegistry.getAdditionalRulesForProject(HighlightingExtenderRegistry.groovy:104)
	at org.codehaus.groovy.eclipse.editor.GroovyConfiguration.createTagScanner(GroovyConfiguration.java:75)
	at org.codehaus.groovy.eclipse.editor.GroovyConfiguration.<init>(GroovyConfiguration.java:64)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.createJavaSourceViewerConfiguration(GroovyEditor.java:1178)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.setPreferenceStore(GroovyEditor.java:592)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput(JavaEditor.java:2550)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput(CompilationUnitEditor.java:1371)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.doSetInput(GroovyEditor.java:949)
	at org.eclipse.ui.texteditor.AbstractTextEditor$19.run(AbstractTextEditor.java:3043)
	at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
	at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756)
	at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2606)
	at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:3061)
	at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:3088)
	at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:798)
	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:647)
	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:313)
	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:180)
	at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:270)
	at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
	at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:473)
	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1254)
	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1207)
	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1606)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:497)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:483)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:225)
	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:213)
	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:778)
	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:677)
	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:638)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2860)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2768)
	at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPage.java:2760)
	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2711)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2707)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2691)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2682)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:378)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:178)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:229)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:208)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:274)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:250)
	at org.eclipse.jdt.internal.ui.packageview.PackageExplorerActionGroup.handleOpen(PackageExplorerActionGroup.java:373)
	at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$4.open(PackageExplorerPart.java:526)
	at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:48)
	at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:845)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:843)
	at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1131)
	at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1235)
	at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:264)
	at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:258)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:298)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3540)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3161)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
	at org.eclipse.jface.window.Window.open(Window.java:801)
	at org.eclipse.ui.internal.views.log.EventDetailsDialog.open(EventDetailsDialog.java:176)
	at org.eclipse.ui.internal.views.log.EventDetailsDialogAction.run(EventDetailsDialogAction.java:98)
	at org.eclipse.ui.internal.views.log.LogView$15.doubleClick(LogView.java:536)
	at org.eclipse.jface.viewers.StructuredViewer$1.run(StructuredViewer.java:824)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.StructuredViewer.fireDoubleClick(StructuredViewer.java:822)
	at org.eclipse.jface.viewers.AbstractTreeViewer.handleDoubleSelect(AbstractTreeViewer.java:1421)
	at org.eclipse.jface.viewers.StructuredViewer$4.widgetDefaultSelected(StructuredViewer.java:1225)
	at org.eclipse.jface.util.OpenStrategy.fireDefaultSelectionEvent(OpenStrategy.java:238)
	at org.eclipse.jface.util.OpenStrategy.access$0(OpenStrategy.java:235)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:296)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3540)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3161)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1408)


 Comments   
Comment by Andrew Eisenberg [ 22/Jun/11 ]

There is a chance you are hitting: https://issuetracker.springsource.com/browse/STS-1854

Please update to the latest Groovy-Eclipse dev build and let me know if you still have the problem.

Comment by Robert Winch [ 22/Jun/11 ]

Thanks for the update. I went ahead and updated to the latest dev build. Since I am unable to reproduce the issue consistently it may take a while to reproduce. I will follow up in a week if it appears to be fixed. If the issue does happen again, then I will respond when it occurs. Thanks again.

Comment by Andrew Eisenberg [ 22/Jun/11 ]

Please keep me posted. The bug I linked to was also a tough one to track down, so no worries if it takes a while to get back. If I don't hear from you by the time of the 2.5.2 release, I'll assume it is fixed.

Comment by Robert Winch [ 24/Jun/11 ]

The issue does not appear to be fixed in Version: 2.5.1.xx-20110620-2000-e36 of Groovy Eclipse which I obtained from http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/. I did notice that the first time when opening the editor I get a different error that the one I posted. I have attached a file named greclipse-stacks.txt with the first and second stack traces (along with comments stating which is which). If there is any more information I can get that would be useful please let me know.

Comment by Robert Winch [ 24/Jun/11 ]

Updated stacktraces

Comment by Andrew Eisenberg [ 24/Jun/11 ]

Thanks for the updates. Do you think that you were always getting the CodeCache problem or is that new?

The CodeCache is related to permgen space and might be caused by Groovy loading too many classes. I would recommend trying some memory settings like this and see if it helps you. You can add this to your eclipse.ini:

-Xmx1024m 
-Xms256m 
-XX:PermSize=64m 
-XX:MaxPermSize=256m 
-XX:ReservedCodeCacheSize=64m

Looking at your settings above, I see that you already have a MaxPermSize of 256. Perhaps bumping up the ReservedCodeCacheSize will help, too.

Comment by Robert Winch [ 26/Jun/11 ]

To be honest I am not certain if I was always getting the Code Cache problems. Let me know if this information would be useful and I can try and figure out if this was occurring with the old version of the plugin.

In the mean time I will bump up the ReservedCodeCacheSize to 64m to see if that helps. The issue tends to take a while to manifest itself. This leaves me wondering if upping the setting might just be delaying the inevitable. Would it help if i was able to capture a dump when the issue occurred to see if there was a leak?

I have also been having some new thoughts on what it might be related to (since I haven't updated the Groovy compiler and it still occurs). I also am wondering if this is related to my use of Git (Note: I use the command line not EGit). Each time I switch branches Eclipse does a rebuild everything. Perhaps something is holding onto my Groovy classes?

One other thing I probably should have mentioned is I upgraded to to STS 2.7.0.M2 when I did the Groovy Eclipse update. I'm not sure how relevant that is, but it is something I should not have left out of my previous post.

Thanks again for all your help.

Comment by Andrew Eisenberg [ 26/Jun/11 ]

Yes, it would help if you could capture a stack dump when this happens.

Also, another thing you can try is to disable DSLD support in your workspace (this will disable some of the new editing enhancements that we have added since 2.5.0). It would be unfortunate if this is causing the problem, but we do need to find out. To disable, you can go to Preferences -> Groovy -> DSLD and check the setting to disable (and then restart).

If you do try to disable DSLD support and you drop the ReservedCodeCacheSize back to the default, then you can see if this is the cause of the problem.

Comment by Robert Winch [ 27/Jun/11 ]

Ok I will try each of these things in turn. As they are probably going to take a bit of time to occur I have listed the order I am going to try to get you information. If it is not the order you prefer it, please let me know and I will gladly re-prioritize.

1) Attempt to capture a stack dump after the issue occurs. I will do this with ReservedCodeCacheSize at the default in order to attempt to get it to occur faster.
2) Try with ReservedCodeCacheSize larger. I did this for a day and I had no issues, but this can occur coincidentally too.
3) Find out if the Code Cache exception occurs in the old plugin version
4) Try to disable DSLD support

Thanks again for your help!

Comment by Andrew Eisenberg [ 27/Jun/11 ]

Yes. This sounds reasonable. Please keep me posted if you find out any more information.

Comment by Robert Winch [ 27/Jun/11 ]

I have a YourKit memory snapshot after the issue occurred, but unfortunately it cannot be compressed under the 10MB limit Jira imposes on attachements. Do you have a suggestion on how I should share it?

Comment by Andrew Eisenberg [ 28/Jun/11 ]

Thanks for grabbing the snapshot. I just shared a dropbox folder with you. You can place the file there. Let me know if you have any problems using it. I used the email address that is linked to your jira account, so you should have received an email about it.

Comment by Robert Winch [ 28/Jun/11 ]

I uploaded the snapshot and it looks like it was successful, but I did get an error on upload so if you have any problems please let me know. I used YourKit EAP version, so if you do not have a license there should not be a problem. I will try to gather information on step #2 next.

Comment by Andrew Eisenberg [ 28/Jun/11 ]

I got your snapshot and I'm having a look right now.

Comment by Andrew Eisenberg [ 28/Jun/11 ]

Unfortunately, I'm not seeing things that are too interesting in the snapshot. I'm looking for instances or classes that come from Groovy or Groovy-Eclipse that are around, but probably shouldn't be. Specifically, I am looking for references to generated classes, closures, etc that have not been garbage collected. These are the things that I would expect would be bloating your CodeCache. It doesn't even look like you PermGen space has been maxed out.

Let me think about this a little more.

Comment by Andrew Eisenberg [ 15/Aug/11 ]

Hi Robert,

Have you seen the code cache problem again recently?

Comment by Robert Winch [ 16/Aug/11 ]

Andrew,

Thank you for following up on this. I have been keeping up to date with the latest dev builds and have not seen this issue for a number of weeks. I am not quite certain if it is fixed or which version fixed the issue as the bug is fairly unpredictable when it occurs.

Cheers,
Rob

Comment by Andrew Eisenberg [ 16/Aug/11 ]

OK. I'll keep this open for a little bit longer and if you see the problem again, please let me know. Otherwise, I will assume that it is now fixed.

Comment by Robert Winch [ 19/Aug/11 ]

I had this issue occur again. The issue occurred immediately after adding a groovy source folder (using the Eclipse build path editor) and then opening a Groovy class within that class. I was not able to get a lot of information because Eclipse shutdown (I believe I accidentally selected the button that is shown with this error to restart eclipse). After Eclipse is restarted everything works again as expected.

My environment has been changed quite a bit. I have attached a new file with the environment. A few highlights are:

It really seems like this issue occurs when a lot of new/updated Groovy code is introduced. Previously I think this may have been related to when I switched branches as mentioned in comment-271504. One other thing that may be relevant is that I use gmaven and m2e integration. I really do not know if that information helps, but thought I would make that as evident as possible.

Thanks again for your help and sorry for not being able to provide more details on this issue.

Comment by Robert Winch [ 19/Aug/11 ]

Attaching updated files for this issue when using STS 2.8.0.M1 and other updates.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

I created GRECLIPSE-1181 and I will be closing this issue. It seems like the code cache problem is unrelated to the original issue, which appears to be fixed.

Please make further comments on that issue.

Comment by Andrew Eisenberg [ 19/Aug/11 ]

Original problem is fixed. See GRECLIPSE-1181 for codecache issue.





[GRECLIPSE-1073] [gpp] beyond the basic support Created: 02/Jun/11  Updated: 09/Aug/12  Resolved: 09/Aug/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.0Release
Fix Version/s: 2.7.1.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Won't Fix  
Labels: wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

collecting together a few tasks that could make life easier.

be good to do:

1) Nature and actions for add/remove groovy++ nature on a project.
2) As well as managing nature, manage add/remove of groovypp jar from the groovy classpath container (we include a compatible version of groovy++ in the plugin)
3) Allow the user to override that level with their own groovypp jar (at least tolerate it) - preference page for pointing at a diff version?
4) Create content type for gpp source in a groovy project - wire .gpp/.grunit to it, they are currently wired to the one existing groovy content type
5) menu actions for quickly moving files to/from .groovy/.gpp

might do:

6) New gpp/grunit file wizard? (or just an option on the existing wizard?)

gpp is far more important to me than grunit, so that would get priority for all these things.



 Comments   
Comment by Andrew Eisenberg [ 09/Aug/12 ]

No more interest in g++ now that Groovy 2.0 has static mode.





[GRECLIPSE-1072] No Javadoc hovers for enum references when enum is defined in Groovy Created: 01/Jun/11  Updated: 01/Jun/11  Resolved: 01/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In this code:

enum Foo {
  /** hallo 123 */
  HALLO,
}
Foo.HALLO

Hover over the reference to HALLO. I would expect there to be Javadoc, but it is not there.



 Comments   
Comment by Andrew Eisenberg [ 01/Jun/11 ]

If the enum definition is moved to a Java file, then Javadoc does appear.

If the enum definition is moved to a different Groovy file, there is still no Javadoc.

Comment by Andy Clement [ 01/Jun/11 ]

fixed





[GRECLIPSE-1071] Wrong return type signature for values() method in enums Created: 01/Jun/11  Updated: 02/Jun/11  Resolved: 02/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This is likely a groovy bug (not greclipse), but I'll raise it here just to be sure.

Create this class in a groovy project:

public enum H {
 FIRST, SECOND
}

Open the AST Viewer
Navigate to Classes -> H -> Methods -> values -> returnType

The name of this ClassNode should be [H;, but instead it is [H. This is likely confusion because of a single character enum type name. When I change 'H' to 'H2', the problem goes away and the return type is correctly [LH2;.

This is causing a problem for content assist in the groovy editor.



 Comments   
Comment by Andy Clement [ 01/Jun/11 ]

I've seen something like this before, can't recall quite what I did about it though.

Comment by Andy Clement [ 02/Jun/11 ]

we patch the array handling in groovyc because it is inconsistent (depending on whether the type is from another source file or resolved through a classloader, it produces names of entirely different formats). I tried to remove the patch and cope with the funkyness but it is just too painful, so I repatched and enhanced the patch for this case.





[GRECLIPSE-1070] [gpp] include a drop of gpp in the greclipse distribution Created: 31/May/11  Updated: 28/Sep/11  Resolved: 28/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

we should look at shipping a gpp library with groovy-eclipse, one compatible with each of the groovy compiler levels we ship (so a 1.7.10 compatible one and a 1.8 compatible one). 'Activating' groovy++ would then be as simple as a menu option which will cause the groovy++ library to be included in the project classpath automatically.



 Comments   
Comment by Jim Morris [ 04/Jul/11 ]

This is a great idea.

But please note at the moment you need the groovypp.jar to compile and the groovypp-all.jar to run. This appears to be the case as different versions of the groovy.jar are used for compile and run.

This is inconvenient as the workaround is to edit the run configuration, delete the default classpath and manually add all the libraries except substitute groovypp-all.jar with groovypp.jar.

A simple include groovy++ config hopefully would do this for you.

Comment by Andy Clement [ 04/Jul/11 ]

> But please note at the moment you need the groovypp.jar to compile and the groovypp-all.jar to run.
> This appears to be the case as different versions of the groovy.jar are used for compile and run.

Yes, I know.

Can I ask what runtime dependencies you have on groovypp? I guess you are using something other than the static binding?

Comment by Andy Clement [ 04/Jul/11 ]

Re-reading your comment on the mailing list:

> I removed the groovy-all from my referenced libraries and told eclipse to include groovy jars, but I still get the same
> error when I try to run it, with just groovypp, again it is when it tries to load logback, maybe there is a
> conflict with logback and grooypp in eclipse?

Can you attach a snippet of code that shows the use of logback and this problem? So far when playing with groovypp, none of my code has a runtime dependency on the bits of groovypp that might have this problem (i.e. it doesn't matter that groovypp (not all) is on the classpath alongside groovy-all, since none of the code with jarjar'd references is loaded at runtime)

Comment by Jim Morris [ 04/Jul/11 ]

The full project is in https://github.com/wolfmanjm/GroovyJoyRovio, Note I switch to use groovy-1.8.0 and tell eclipse to include the groovy libs.

The issue is if you add groovypp-all-0.4.268_1.8.0.jar to the build path you get an error immediately even with no @Typed anywhere.

If you add groovypp-0.4.268_1.8.0.jar to the build path instead you get no error, however if you run it you get an error.

So to be able to run you need to remove the default classpath in the run configuration and manually add a new one substituting the groovypp-all for the groovypp.

As far as I know I have no other dependencies that require groovypp, and I think the error with logback maybe that it is the first thing to load. You can see all the jars I load in the .classpath of the project, note however that what I have checked in does not include the groovypp stuff yet, however the RovioJoystick.groovy class is the one I was trying to make @Typed. And it works if I change the runtime classpath.

Comment by Andy Clement [ 04/Jul/11 ]

> The issue is if you add groovypp-all-0.4.268_1.8.0.jar to the build path you get an error immediately even with no @Typed anywhere.

Yep, I'd expect that, you cannot use groovypp-all because we use groovy without the all to compile code.

I've just never seen an example before where running the code causes the problematic stuff to be loaded/run (the code that mismatches between groovypp-all and groovy (not all)). So far in all my examples the Typed related code has only been run at compile time.

Thanks for the link, I will take a look at that project.

Comment by Andy Clement [ 04/Jul/11 ]

and it does seem silly that we compile with groovy (not -all) and yet add groovy-all in the classpath container. It just doesn't normally cause an issue because the section of groovy-all where jarjar'd refs exist is not loaded at runtime and run with incompatible code.

Comment by Andy Clement [ 04/Jul/11 ]

I cloned the repo and added groovypp-0.4.268_1.8.0.jar to the classpath - it compiles OK (haven't put @Typed anywhere), but then I'm unsure which part of it to run, I see multiple classes with a main. I try to run each of them (RunAs>JavaApplication), but they fail as expected (missing a User id/password, etc). Which one do you recommend I launch to see a problem related to groovypp?

My suspicion is that the existence of logback.groovy is causing the problem. Given that it is a resource, it will be getting parsed/compiled at runtime, which will involve initializing the compiler, which will drive the search for ast transforms, which will discover the groovy++ transforms in the groovypp jar and then fail because they aren't compatible with groovy-all, but I can't seem to make things fail in order to check what happens if I remove logback.groovy.

Comment by Jim Morris [ 04/Jul/11 ]

Ok so that is as far as I get with groovypp.jar it compiles.

However when I try to run RovioJoystick I get it failing before it gets anywhere...
(Do make sure to add -Djava.library.path=./libs to the VM arguments in the Run Configuration as that does not get saved anywhere I can checkin). That is the only addition to the Run Configuration for RovioJoystick.

I also think it maybe logback.groovy, however it should not be compiled as I have specifically excluded it in the Groovy preferences by enabling script folder support. I forgot to mention that. I added src/main/resources/*/.groovy to the exclude list.

Could it be logback has some dependency on groovy that is undocumented?

It should fail before it finds out there is no joystick (BTW I run on linux have not tried on windows).

I get The following error in the console window...

Failed to instantiate [ch.qos.logback.classic.LoggerContext]
Reported exception:
java.lang.NoClassDefFoundError: org/objectweb/asm/Opcodes
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
	at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:696)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.addPhaseOperationsForGlobalTransforms(ASTTransformationVisitor.java:285)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.doAddGlobalTransforms(ASTTransformationVisitor.java:266)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.addGlobalTransforms(ASTTransformationVisitor.java:187)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.addPhaseOperations(ASTTransformationVisitor.java:150)
	at org.codehaus.groovy.control.CompilationUnit.<init>(CompilationUnit.java:188)
	at org.codehaus.groovy.control.CompilationUnit.<init>(CompilationUnit.java:120)
	at groovy.lang.GroovyClassLoader.createCompilationUnit(GroovyClassLoader.java:480)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:294)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:743)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:770)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:761)
	at groovy.lang.GroovyShell$parse.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:48)
	at ch.qos.logback.classic.gaffer.GafferConfigurator$run.callCurrent(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
	at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:37)
	at ch.qos.logback.classic.gaffer.GafferUtil.runGafferConfiguratorOn(GafferUtil.java:44)
	at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:67)
	at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150)
	at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85)
	at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
	at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
	at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
	at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
	at org.slf4j.LoggerFactory$getLogger.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at com.e4net.rovio.joystick.RovioJoystick.<clinit>(RovioJoystick.groovy:21)
Caused by: java.lang.ClassNotFoundException: org.objectweb.asm.Opcodes
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
	... 51 more
Comment by Jim Morris [ 04/Jul/11 ]

Oh I am using eclipse 3.6.2.r362_v20110210
Groovy-Eclipse plugin Version: 2.5.2.xx-20110630-1100-e36

Comment by Jim Morris [ 04/Jul/11 ]

BTW I get the same error if I remove logback.groovy

Comment by Jim Morris [ 04/Jul/11 ]

I don't think it makes any difference but you can do a git pull, I changed the classpath to include the groovy libs rather than explicitly including groovy-all in the referenced libs.

Comment by Andy Clement [ 04/Jul/11 ]

Ok, thanks for the extra bits of information, very useful! I think we can see what is happening here. As suspected it is that there is an attempt to use the groovy compiler at runtime. The stacktrace you included (and that I've recreated) shows that. We can see it going into here:

at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:48) // some kind of logback initialization

into:

at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731) // presumably processing logback.groovy

into:

at org.codehaus.groovy.transform.ASTTransformationVisitor.addPhaseOperationsForGlobalTransforms(ASTTransformationVisitor.java:285) // discovered the groovypp transform from groovypp and trying to classload it

into:

java.lang.NoClassDefFoundError: org/objectweb/asm/Opcodes // the transform had a dependency on Opcodes which is not in groovy-all (it is called something else in there, it has been jarjar'd - so the noclassdeffounderror)

The reason logback.groovy is being processed by that groovyclassloader is because it cannot be found in compiled form in the output folder for the project, but the classloader can see it in source form so attempts to compile it at runtime. That is because you have tagged it as a script, so it won't get compiled to the output folder. (this is fine, I'm just explaining why everything is happening). If you don't tag logback.groovy as a script, it will be compiled and then there will be no need to use the compiler at runtime and the app will work as expected.

> BTW I get the same error if I remove logback.groovy

I don't understand that... it isn't what I see. I removed logback.groovy from the project and did a full build of Rovio, then when I next run there is no error (about Opcodes). This is what I would expect. Commenting out logback wouldn't be enough, it has to be completely removed.

A way to work around this is just to keep the transform dependency happy - you don't care about that transform running at 'runtime', but as it is being loaded it will need some of its dependencies. I solved it by adding the asm-3.2.jar to the project classpath (from a groovy 1.8.0 distribution) in addition to groovypp.jar. The transform then finds the dependency it has and is happy, although it has no effect as none of your code is @Typed or in a .gpp file.

Given that using the compiler at runtime isn't uncommon, I need to think about the best way to deal with this.

p.s.

> (Do make sure to add -Djava.library.path=./libs to the VM arguments in the Run Configuration as that does not get saved anywhere I can checkin)

Launch configurations can be tagged as persistent, then you'd have a XXX.launch file in your project that you could share in a repo.

Comment by Jim Morris [ 04/Jul/11 ]

Thank you for the very complete analysis.

FYI logback will not accept logback.groovy if it is compiled, it wants either a logback.xml or a logback.groovy, if the logback.groovy gets complied it is not found or used, which is why I had to force it to treat it as a script.

I'll try removing it again and recompiling.

I'll also try the workaround of adding asm-3.2.jar, as that is better than creating a custom launch configuration.

Also thanks for the tip on making a launch configuration persistent. Didn't know about that.

Comment by Andy Clement [ 04/Jul/11 ]

> FYI logback will not accept logback.groovy if it is compiled, it wants either a logback.xml or a logback.groovy, if the logback.groovy gets complied it is not found or used, which is why I had to force it to treat it as a script.

Thanks for setting me straight, I've never used logback. I had a thought after I wrote that last comment that the reason it worked when I let it be compiled is because the file 'logback.groovy' would not be in the output folder, effectively behaving the same as our case when it isn't there at all (so the same as removing it entirely).

(Whilst playing around in the project, I did find something else. We do seem to be failing to do proper full recompiles of projects when things are either marked as scripts or no longer marked as scripts - I think that is a separate jira.)

I appreciate asm-3.2.jar isn't a great workaround, but hopefully it can get you going whilst I think about the proper solution.

Comment by Jim Morris [ 05/Jul/11 ]

Hi, yea logback unlike log4j has a decent default, so if there is no logback.xml or logback.groovy it uses a default configuration.

I have confirmed that removing the logback.groovy and fully recompiling (ie clean) did in fact also cure the issue, I did not think that a clean would be required.

I also confirm that simply adding asm-32.jar fixed all my issues, and is not such a bad work around, I can certainly live with it.

Although I have a concern that my eclipse configuration differs somewhat from my buildr configuration in that when I deploy with buildr I need to use groovypp-all and if I were to deploy with eclipse I would need groovypp.jar. But I don't think that is really an issue for greclipse.

Thanks and I look forward to the future seemless integration of groovy++ into greclipse

Comment by Andrew Eisenberg [ 28/Sep/11 ]

Resolving this issue since gpp is now included in groovy-eclipse. Any further issues with gpp should be discussed in a new bug.





[GRECLIPSE-1069] [gpp] support/test .gpp (and grunit, any others?) file suffixes Created: 31/May/11  Updated: 02/Jun/11  Resolved: 02/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Improvement Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

we should review the file extension mechanism exploited in groovyc by groovy++, see if it will interfere with what we would normally do in eclipse (define .gpp/etc as groovy content type). The outcome of this jira may just be defining the content type and writing some tests, but it is worth making sure by reviewing the internals.



 Comments   
Comment by Andy Clement [ 02/Jun/11 ]

Reviewed the plugin mechanism that was being used - it won't cause us issues. Also activated .gpp/.grunit as groovy content types. More work to be done for really natural gpp support, but adding the right groovypp level to a project is enough to get started now.





[GRECLIPSE-1068] m2e support does not support the current 0.13.x m2e development stream Created: 28/May/11  Updated: 07/Sep/11  Resolved: 07/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Maven integration, Project Settings
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Benson Margulies Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File groovy-m2eclipse.GRECLIPSE-1068.patch    
Number of attachments : 1

 Description   

It would be helpful to have an update of the groovy m2e support that works with the new 0.13 stuff at M2e. I might be able to help with this.



 Comments   
Comment by Andrew Eisenberg [ 29/May/11 ]

I'm not too familiar with these changes. Can you elaborate? Or even better, submitting a patch would be even more helpful.

Comment by Benson Margulies [ 29/May/11 ]

Can I believe the web page on how to work with greclipse? If so, I'll make you a patch to 0.13.

Comment by Andrew Eisenberg [ 30/May/11 ]

I'm not sure which web page you are looking at. I had a look at:
http://docs.codehaus.org/display/GROOVY/Getting+Started+With+Groovy-Eclipse+Source+Code

It was mostly right. I made a couple of clarifications and fixes.

You don't really need to go that route. All you need to do is install the source code feature for the m2e integration. And then do File -> Import... -> Plug-in Development -> (Check the box Import as Projects with source folders) -> Choose org.codehaus.groovy.m2eclipse

This will import the project with all the source folders. You can make some changes from there and send me the patch.

(Now that I think about it, I should probably update the wiki with the information above.)

Comment by Benson Margulies [ 30/May/11 ]

This is a first cut at the patch. What I could really use is a maven project that uses the gmaven-plugin to test it on.

Comment by Andrew Eisenberg [ 30/May/11 ]

Thanks, Benson. I'll have a look at this. Here is a relatively large groovy-maven project that I am currently using to test the groovy-eclipse-compiler for maven:

https://test.kuali.org/svn/rice/trunk

You may have a problem because one of the required jars is not available through a public repository. It will be a compile problem, so it shouldn't affect whether or not the m2e integration is working. But, if you want it, I can send it to you.

Comment by Benson Margulies [ 30/May/11 ]

patch including test case.

Comment by Benson Margulies [ 30/May/11 ]

Andrew,

I borrowed a test case from the gmaven project itself.

It's not working yet, and I'm not really understanding what's going on.

I may push a copy to github so that i can try to get Igor to help. Or, you could have a look and see if you can make any sense of it. The configurator gets an exception claiming that the project does not exist.

--benson

Comment by Benson Margulies [ 30/May/11 ]

Andrew,

As background, I had the proverbial devil's time moving my checkstyle and pmd support from 0.12 to 0.13. You can find them at https://github.com/bimargulies/m2e-code-quality; there's a separate branch for 0.13. I think that Igor and friends may be somewhat tired of me, and it might work better, if you are willing, if you picked up from here and harassed them as needed to help make it work.

--benson

Comment by Andrew Eisenberg [ 30/May/11 ]

What is the current problem with the existing m2e integration for greclipse?

I am reluctant to spend too much time in this area since we will be releasing the groovy-eclipse-compiler plugin for maven that will solve many of the stub problems that gmaven has. It should also compile much faster (about 2x faster according to my own tests).

Using this new approach, you will not need a separate configurator. The JDT configurator should be sufficient as long as you explicitly specify adding the groovy nature to your project.

Comment by Andrew Eisenberg [ 30/May/11 ]

That being said, there are some things that the new approach will not handle (yet), such as generating stubs for groovy doc. So for now, we should be supporting gmaven in Groovy-Eclipse.

Comment by Benson Margulies [ 30/May/11 ]

The basic problem is that Igor and friends changed everything on their way into the eclipse foundation. Package names and OSGI bundle names to start with, and then they added this lifecycle-configuration-mapping business. Things that worked with 0.12 just don't work with 0.13, which means they won't work in eclipse 3.7, or even in the version of things that the m2e gang is supporting for the forseeable in 3.6.

If you're new toy will hit the streets fairly soon, we can all probably live without any m2e support until it's out there, thought you'll still need to find your way through the 0.13 thicket in settings up the new one.

Comment by Andrew Eisenberg [ 30/May/11 ]

So, they had to break backwards compatibility to move to Eclipse. This means that making the changes would break all users of 0.12.

Can you post the exception you are getting and I will see if it makes sense to me?

Comment by Benson Margulies [ 30/May/11 ]

Configuration location:
file:/Users/benson/ws/greclipse/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/
Configuration file:
file:/Users/benson/ws/greclipse/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/config.ini loaded
Install location:
file:/opt/eclipse-helios-sr2/eclipse/
Framework located:
file:/opt/eclipse-helios-sr2/eclipse/plugins/org.eclipse.osgi_3.6.2.R36x_v20110210.jar
Framework classpath:
file:/opt/eclipse-helios-sr2/eclipse/plugins/org.eclipse.osgi_3.6.2.R36x_v20110210.jar
Splash location:
/opt/eclipse-helios-sr2/eclipse/plugins/org.eclipse.platform_3.6.2.v201102101200/splash.bmp
Debug options:
file:/Users/benson/ws/greclipse/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/.options loaded
Time to load bundles: 59
!SESSION 2011-05-30 16:49:00.538 -----------------------------------------------
eclipse.buildId=M20110210-1200
java.version=1.6.0_24
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments: -product org.eclipse.sdk.ide
Command-line arguments: -product org.eclipse.sdk.ide -data /Users/benson/ws/greclipse/../runtime-EclipseApplication -dev file:/Users/benson/ws/greclipse/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/dev.properties -debug /Users/benson/ws/greclipse/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/.options -os macosx -ws cocoa -arch x86_64 -consoleLog

!ENTRY org.eclipse.osgi 2 0 2011-05-30 16:49:09.213
!MESSAGE One or more bundles are not resolved because the following root constraints are not resolved:
!SUBENTRY 1 org.eclipse.osgi 2 0 2011-05-30 16:49:09.214
!MESSAGE Bundle reference:file:/opt/eclipse-helios-sr2/eclipse/plugins/org.eclipse.m2e.usagedata_0.13.0.201105252313.jar was not resolved.
!SUBENTRY 2 org.eclipse.m2e.usagedata 2 0 2011-05-30 16:49:09.214
!MESSAGE Missing required bundle org.eclipse.epp.usagedata.gathering_0.0.0.

!ENTRY org.eclipse.osgi 2 0 2011-05-30 16:49:09.216
!MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists:
!SUBENTRY 1 org.eclipse.osgi 2 0 2011-05-30 16:49:09.216
!MESSAGE Bundle org.eclipse.m2e.usagedata_0.13.0.201105252313 [190] was not resolved.
!SUBENTRY 2 org.eclipse.m2e.usagedata 2 0 2011-05-30 16:49:09.216
!MESSAGE Missing required bundle org.eclipse.epp.usagedata.gathering_0.0.0.
Starting application: 8681
Application Started: 14249
16:49:22.735 [Thread-1] DEBUG o.e.m.c.i.p.r.ProjectRegistryRefreshJob - Queued refresh request: []
16:49:22.872 [ModalContext] DEBUG o.e.m.c.u.i.w.MavenImportWizard - About to calculate lifecycle mapping configuration
16:49:23.790 [Worker-1] DEBUG o.e.m.c.i.p.r.ProjectRegistryManager - Refreshing: []
16:49:24.708 [Worker-1] DEBUG o.e.m.c.i.p.r.ProjectRegistryManager - Refreshed: []
16:49:25.834 [Worker-4] INFO o.e.m.c.i.i.nexus.NexusIndexManager - Updating index for repository: central|http://repo1.maven.org/maven2
16:49:25.873 [Worker-4] DEBUG c.n.http.client.RequestBuilderBase - setUrl hasn't been invoked. Using http://localhost
16:49:26.079 [Worker-4] DEBUG c.n.h.c.p.n.NettyAsyncHttpProvider -
Non cached request
DefaultHttpRequest(chunked: false)
GET /maven2/.index/nexus-maven-repository-index.properties HTTP/1.1
Host: repo1.maven.org
Accept-Encoding: gzip
Connection: keep-alive
Accept: /
User-Agent: m2e/3.6.2.R36x_v20110210/0.13.0.201105252313

using Channel
[id: 0x3acc0a7c, /10.1.6.245:59094 => repo1.maven.org/207.223.240.88:80]

16:49:26.154 New I/O client worker #1-1 DEBUG c.n.h.c.p.n.NettyAsyncHttpProvider -

Request DefaultHttpRequest(chunked: false)
GET /maven2/.index/nexus-maven-repository-index.properties HTTP/1.1
Host: repo1.maven.org
Accept-Encoding: gzip
Connection: keep-alive
Accept: /
User-Agent: m2e/3.6.2.R36x_v20110210/0.13.0.201105252313

Response DefaultHttpResponse(chunked: false)
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.0.1
Date: Mon, 30 May 2011 20:49:26 GMT
Content-Type: text/html
Content-Length: 160
Connection: keep-alive
Location: http://mirrors.ibiblio.org/pub/mirrors/maven2/dot-index/nexus-maven-repository-index.properties

16:49:26.154 New I/O client worker #1-1 DEBUG c.n.h.c.p.n.NettyAsyncHttpProvider - Redirecting to http://mirrors.ibiblio.org/pub/mirrors/maven2/dot-index/nexus-maven-repository-index.properties
16:49:26.157 New I/O client worker #1-1 DEBUG c.n.h.c.p.n.NettyAsyncHttpProvider -
Non cached request
DefaultHttpRequest(chunked: false)
GET /pub/mirrors/maven2/dot-index/nexus-maven-repository-index.properties HTTP/1.1
Host: mirrors.ibiblio.org
Accept-Encoding: gzip
Connection: keep-alive
Accept: /
User-Agent: m2e/3.6.2.R36x_v20110210/0.13.0.201105252313

using Channel
[id: 0x717f0c8f]

16:49:26.277 New I/O client worker #1-2 DEBUG c.n.h.c.p.n.NettyAsyncHttpProvider -

Request DefaultHttpRequest(chunked: false)
GET /pub/mirrors/maven2/dot-index/nexus-maven-repository-index.properties HTTP/1.1
Host: mirrors.ibiblio.org
Accept-Encoding: gzip
Connection: keep-alive
Accept: /
User-Agent: m2e/3.6.2.R36x_v20110210/0.13.0.201105252313

Response DefaultHttpResponse(chunked: false)
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Accept-Ranges: bytes
ETag: "2451114964"
Last-Modified: Mon, 30 May 2011 08:35:30 GMT
Content-Length: 1130
Date: Mon, 30 May 2011 20:49:26 GMT
Server: lighttpd/1.4.26

16:49:26.287 New I/O client worker #1-2 DEBUG c.n.h.c.p.n.NettyAsyncHttpProvider - Adding uri: http://mirrors.ibiblio.org:80 for channel [id: 0x717f0c8f, /10.1.6.245:59095 => mirrors.ibiblio.org/152.19.134.44:80]
16:49:28.662 [Worker-4] INFO o.e.m.c.i.i.nexus.NexusIndexManager - Updated index for repository: central|http://repo1.maven.org/maven2 in 2828 ms
16:49:39.423 [ModalContext] DEBUG o.e.m.c.u.i.w.MavenImportWizard - About to calculate lifecycle mapping configuration
16:49:39.424 [ModalContext] DEBUG o.e.m.c.internal.embedder.MavenImpl - Reading Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml
16:49:39.646 [ModalContext] DEBUG o.e.m.c.internal.embedder.MavenImpl - Read Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml in 222 ms
16:49:42.784 [ModalContext] WARN o.e.m.i.discovery.MavenDiscovery - CatalogItem org.eclipse.m2e.discovery.lifecyclemapping.m2e-egit does not contain lifecycle mapping metadata
16:49:42.784 [ModalContext] WARN o.e.m.i.discovery.MavenDiscovery - CatalogItem org.eclipse.m2e.discovery.lifecyclemapping.m2e-cvs does not contain lifecycle mapping metadata
16:49:42.786 [ModalContext] WARN o.e.m.i.discovery.MavenDiscovery - CatalogItem org.eclipse.m2e.discovery.lifecyclemapping.m2e-subversive does not contain lifecycle mapping metadata
16:49:42.787 [ModalContext] WARN o.e.m.i.discovery.MavenDiscovery - CatalogItem org.eclipse.m2e.discovery.maven-runtime-3.0.3 does not contain lifecycle mapping metadata
16:49:46.188 [Worker-3] DEBUG o.e.m.c.i.p.r.ProjectRegistryManager - Refreshing: [/m2e-test-project/pom.xml]
16:49:46.192 [Worker-3] DEBUG o.e.m.c.internal.embedder.MavenImpl - Reading Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml
16:49:46.267 [Worker-3] DEBUG o.e.m.c.internal.embedder.MavenImpl - Read Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml in 75 ms
16:49:46.592 [Worker-3] DEBUG o.e.m.c.i.l.LifecycleMappingFactory - Loading lifecycle mapping for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml.
16:49:46.929 [Worker-3] INFO o.e.m.c.i.l.LifecycleMappingFactory - Using org.eclipse.m2e.jdt.JarLifecycleMapping lifecycle mapping for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml.
16:49:46.929 [Worker-3] DEBUG o.e.m.c.i.l.LifecycleMappingFactory - Loaded lifecycle mapping in 338 ms for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml.
16:49:46.930 [Worker-3] DEBUG o.e.m.c.i.p.r.DefaultMavenDependencyResolver - Resolving dependencies for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml
16:49:46.930 [Worker-3] DEBUG o.e.m.c.internal.embedder.MavenImpl - Reading Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml
16:49:47.262 [Worker-3] DEBUG o.e.m.c.internal.embedder.MavenImpl - Read Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml in 332 ms
16:49:47.264 [Worker-3] DEBUG o.e.m.c.i.p.r.DefaultMavenDependencyResolver - Resolved dependencies for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml in 334 ms
16:49:47.264 [Worker-3] DEBUG o.e.m.c.i.p.r.ProjectRegistryManager - Refreshed: [/m2e-test-project/pom.xml]
16:49:47.272 [Worker-3] DEBUG o.e.m.c.i.markers.MavenMarkerManager - Created marker 'Project configuration is not up-to-date with pom.xml. Run project configuration update' on resource '/m2e-test-project'.
16:49:47.326 [Worker-3] ERROR o.e.m.jdt.internal.BuildPathManager - m2e-test-project does not exist
org.eclipse.jdt.core.JavaModelException: m2e-test-project does not exist
at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:492) ~[org.eclipse.jdt.core_3.6.2.xx-20110527-2000-e36.jar:na]
at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:2163) ~[org.eclipse.jdt.core_3.6.2.xx-20110527-2000-e36.jar:na]
at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1867) ~[org.eclipse.jdt.core_3.6.2.xx-20110527-2000-e36.jar:na]
at org.eclipse.jdt.internal.core.JavaProject.getRawClasspath(JavaProject.java:1889) ~[org.eclipse.jdt.core_3.6.2.xx-20110527-2000-e36.jar:na]
at org.codehaus.groovy.m2eclipse.GroovyProjectConfigurator.hasEntry(GroovyProjectConfigurator.java:90) ~[na:na]
at org.codehaus.groovy.m2eclipse.GroovyProjectConfigurator.configureClasspath(GroovyProjectConfigurator.java:65) ~[na:na]
at org.eclipse.m2e.jdt.internal.DefaultClasspathManagerDelegate.populateClasspath(DefaultClasspathManagerDelegate.java:61) ~[org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.getClasspath(BuildPathManager.java:294) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.getClasspath(BuildPathManager.java:402) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.getClasspath(BuildPathManager.java:383) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.getClasspath(BuildPathManager.java:410) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.updateClasspath(BuildPathManager.java:229) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.mavenProjectChanged(BuildPathManager.java:218) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.notifyProjectChangeListeners(ProjectRegistryManager.java:724) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.applyMutableProjectRegistry(ProjectRegistryManager.java:847) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:280) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.configureNewMavenProject(ProjectConfigurationManager.java:212) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.importProjects(ProjectConfigurationManager.java:152) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.ui.internal.wizards.MavenImportWizard$1.doCreateMavenProjects(MavenImportWizard.java:164) [org.eclipse.m2e.core.ui_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.ui.internal.wizards.AbstractCreateMavenProjectsOperation.run(AbstractCreateMavenProjectsOperation.java:73) [org.eclipse.m2e.core.ui_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.ui.internal.wizards.MavenImportWizard$3.runInWorkspace(MavenImportWizard.java:249) [org.eclipse.m2e.core.ui_0.13.0.201105252313.jar:na]
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) [org.eclipse.core.jobs_3.5.1.R36x_v20100824.jar:na]
16:49:47.335 [Worker-3] DEBUG o.e.m.c.i.p.ProjectConfigurationManager - Updating project configuration for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml.

!ENTRY org.eclipse.core.resources 2 568 2011-05-30 16:49:59.269
!MESSAGE Problems encountered while setting project description.
!SUBENTRY 1 org.eclipse.core.resources 2 35 2011-05-30 16:49:59.269
!MESSAGE Nature org.eclipse.jdt.groovy.core.groovyNature is missing prerequisite nature: org.eclipse.jdt.core.javanature.
16:49:59.427 [Worker-0] DEBUG o.e.m.c.i.builder.MavenBuilder - Building project m2e-test-project
16:49:59.427 [Worker-0] DEBUG o.e.m.c.i.p.r.ProjectRegistryManager - Refreshing: [/m2e-test-project/pom.xml]
16:49:59.429 [Worker-0] DEBUG o.e.m.c.internal.embedder.MavenImpl - Reading Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml
16:49:59.435 [Worker-0] DEBUG o.e.m.c.internal.embedder.MavenImpl - Read Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml in 6 ms
16:49:59.486 [Worker-0] DEBUG o.e.m.c.i.l.LifecycleMappingFactory - Loading lifecycle mapping for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml.
16:49:59.522 [Worker-0] INFO o.e.m.c.i.l.LifecycleMappingFactory - Using org.eclipse.m2e.jdt.JarLifecycleMapping lifecycle mapping for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml.
16:49:59.522 [Worker-0] DEBUG o.e.m.c.i.l.LifecycleMappingFactory - Loaded lifecycle mapping in 36 ms for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml.
16:49:59.523 [Worker-0] DEBUG o.e.m.c.i.p.r.DefaultMavenDependencyResolver - Resolving dependencies for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml
16:49:59.523 [Worker-0] DEBUG o.e.m.c.internal.embedder.MavenImpl - Reading Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml
16:49:59.655 [Worker-0] DEBUG o.e.m.c.internal.embedder.MavenImpl - Read Maven project: /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml in 132 ms
16:49:59.655 [Worker-0] DEBUG o.e.m.c.i.p.r.DefaultMavenDependencyResolver - Resolved dependencies for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml in 132 ms
16:49:59.656 [Worker-0] DEBUG o.e.m.c.i.p.r.ProjectRegistryManager - Refreshed: [/m2e-test-project/pom.xml]
16:49:59.657 [Worker-0] DEBUG o.e.m.c.i.markers.MavenMarkerManager - Created marker 'Project configuration is not up-to-date with pom.xml. Run project configuration update' on resource '/m2e-test-project'.
16:49:59.664 [Worker-0] ERROR o.e.m.jdt.internal.BuildPathManager - m2e-test-project does not exist
org.eclipse.jdt.core.JavaModelException: m2e-test-project does not exist
at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:492) ~[org.eclipse.jdt.core_3.6.2.xx-20110527-2000-e36.jar:na]
at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:2163) ~[org.eclipse.jdt.core_3.6.2.xx-20110527-2000-e36.jar:na]
at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1867) ~[org.eclipse.jdt.core_3.6.2.xx-20110527-2000-e36.jar:na]
at org.eclipse.jdt.internal.core.JavaProject.getRawClasspath(JavaProject.java:1889) ~[org.eclipse.jdt.core_3.6.2.xx-20110527-2000-e36.jar:na]
at org.codehaus.groovy.m2eclipse.GroovyProjectConfigurator.hasEntry(GroovyProjectConfigurator.java:90) ~[na:na]
at org.codehaus.groovy.m2eclipse.GroovyProjectConfigurator.configureClasspath(GroovyProjectConfigurator.java:65) ~[na:na]
at org.eclipse.m2e.jdt.internal.DefaultClasspathManagerDelegate.populateClasspath(DefaultClasspathManagerDelegate.java:61) ~[org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.getClasspath(BuildPathManager.java:294) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.getClasspath(BuildPathManager.java:402) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.getClasspath(BuildPathManager.java:383) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.getClasspath(BuildPathManager.java:410) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.updateClasspath(BuildPathManager.java:229) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.jdt.internal.BuildPathManager.mavenProjectChanged(BuildPathManager.java:218) [org.eclipse.m2e.jdt_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.notifyProjectChangeListeners(ProjectRegistryManager.java:724) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.applyMutableProjectRegistry(ProjectRegistryManager.java:847) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:280) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.project.registry.MavenProjectManager.refresh(MavenProjectManager.java:58) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:120) [org.eclipse.m2e.core_0.13.0.201105252313.jar:na]
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) [org.eclipse.equinox.common_3.6.0.v20100503.jar:na]
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) [org.eclipse.equinox.common_3.6.0.v20100503.jar:na]
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242) [org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar:na]
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) [org.eclipse.core.jobs_3.5.1.R36x_v20100824.jar:na]
16:49:59.666 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Build participants for MavenProject: org.codehaus.groovy.greclipse:m2e-test-project:1-SNAPSHOT @ /Users/benson/asf/greclipse/extras/m2eclipse-test-case/pom.xml
16:49:59.666 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.codehaus.gmaven:gmaven-plugin:1.3:generateStubs (execution: compile, phase: generate-sources)
16:49:59.667 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: configurator
16:49:59.667 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator id: org.codehaus.groovy.m2eclipse.configurator1
16:49:59.667 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator: org.codehaus.groovy.m2eclipse.GroovyProjectConfigurator
16:49:59.668 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources (execution: default-resources, phase: process-resources)
16:49:59.668 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: execute
16:49:59.683 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (execution: default-compile, phase: compile)
16:49:59.684 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: configurator
16:49:59.684 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator id: org.eclipse.m2e.jdt.javaConfigurator
16:49:59.684 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator: org.eclipse.m2e.jdt.internal.JavaProjectConfigurator
16:49:59.685 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.codehaus.gmaven:gmaven-plugin:1.3:compile (execution: compile, phase: compile)
16:49:59.685 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: configurator
16:49:59.685 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator id: org.codehaus.groovy.m2eclipse.configurator1
16:49:59.685 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator: org.codehaus.groovy.m2eclipse.GroovyProjectConfigurator
16:49:59.686 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.codehaus.gmaven:gmaven-plugin:1.3:generateTestStubs (execution: compile, phase: generate-test-sources)
16:49:59.686 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: configurator
16:49:59.686 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator id: org.codehaus.groovy.m2eclipse.configurator1
16:49:59.687 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator: org.codehaus.groovy.m2eclipse.GroovyProjectConfigurator
16:49:59.688 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.apache.maven.plugins:maven-resources-plugin:2.4.3:testResources (execution: default-testResources, phase: process-test-resources)
16:49:59.688 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: execute
16:49:59.689 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (execution: default-testCompile, phase: test-compile)
16:49:59.689 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: configurator
16:49:59.689 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator id: org.eclipse.m2e.jdt.javaConfigurator
16:49:59.689 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator: org.eclipse.m2e.jdt.internal.JavaProjectConfigurator
16:49:59.690 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.codehaus.gmaven:gmaven-plugin:1.3:testCompile (execution: compile, phase: test-compile)
16:49:59.690 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: configurator
16:49:59.690 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator id: org.codehaus.groovy.m2eclipse.configurator1
16:49:59.690 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator: org.codehaus.groovy.m2eclipse.GroovyProjectConfigurator
16:49:59.691 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (execution: default-test, phase: test)
16:49:59.691 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.codehaus.gmaven:gmaven-plugin:1.3:execute (execution: execute, phase: test)
16:49:59.691 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.apache.maven.plugins:maven-jar-plugin:2.3.1:jar (execution: default-jar, phase: package)
16:49:59.691 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Action: configurator
16:49:59.691 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator id: org.sonatype.m2e.mavenarchiver.pomProperties
16:49:59.691 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Project configurator: org.sonatype.m2e.mavenarchiver.pomproperties.internal.PomPropertiesConfigurator
16:49:59.766 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Build participant: org.sonatype.m2e.mavenarchiver.pomproperties.internal.PomPropertiesConfigurator$1
16:49:59.766 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.apache.maven.plugins:maven-install-plugin:2.3.1:install (execution: default-install, phase: install)
16:49:59.766 [Worker-0] DEBUG o.e.m.c.p.c.AbstractCustomizableLifecycleMapping - Mojo execution key: org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (execution: default-deploy, phase: deploy)
16:49:59.767 [Worker-0] DEBUG o.e.m.c.i.builder.MavenBuilder - Executing build participant org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant for plugin execution org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources (execution: default-resources, phase: process-resources)
16:50:00.034 [Worker-0] WARN o.e.m.c.i.embedder.EclipseLogger - Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
16:50:00.034 [Worker-0] INFO o.e.m.c.i.embedder.EclipseLogger - skip non existing resourceDirectory /Users/benson/asf/greclipse/extras/m2eclipse-test-case/src/main/resources
16:50:00.034 [Worker-0] DEBUG o.e.m.c.i.builder.MavenBuilder - Executing build participant org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant for plugin execution org.apache.maven.plugins:maven-resources-plugin:2.4.3:testResources (execution: default-testResources, phase: process-test-resources)
16:50:00.037 [Worker-0] WARN o.e.m.c.i.embedder.EclipseLogger - Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
16:50:00.037 [Worker-0] INFO o.e.m.c.i.embedder.EclipseLogger - skip non existing resourceDirectory /Users/benson/asf/greclipse/extras/m2eclipse-test-case/src/test/resources
16:50:00.037 [Worker-0] DEBUG o.e.m.c.i.builder.MavenBuilder - Executing build participant org.sonatype.m2e.mavenarchiver.pomproperties.internal.PomPropertiesConfigurator$1 for plugin execution org.apache.maven.plugins:maven-jar-plugin:2.3.1:jar (execution: default-jar, phase: package)
16:50:00.043 [Worker-0] DEBUG o.e.m.c.i.builder.MavenBuilder - Built project m2e-test-project in 616 ms

Comment by Andrew Eisenberg [ 30/May/11 ]

This looks to me like it is a problem with the original configurator. The java nature is not being explicitly added to the project being configured. To see if this is the problem, can you add this to your pom:


			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-eclipse-plugin</artifactId>
				<version>2.8</version>
				<configuration>
					<additionalProjectnatures>
						<projectnature>org.eclipse.jdt.core.javanature</projectnature>
					</additionalProjectnatures>
				</configuration>
			</plugin>

If this does fix your problem, then we need to explicitly add the java nature if it doesn't already exist. I can get that code snippet together and paste it here so you can try it out.

Comment by Benson Margulies [ 30/May/11 ]

Andrew,

I could add the nature with a text editor applied to .project for an experiment, but it seems nuts. The project is an ordinary 'jar' packaging project; m2e should add a java nature unless someone does something to prevent it. Or does the configurator in here inherit from some base class that has the effect making it the local task?

--benson

Comment by Benson Margulies [ 30/May/11 ]

If I add the java nature m2e promptly subtracts it.

Comment by Benson Margulies [ 30/May/11 ]

I seem to have attracted Igor's attention. A fix may be forthcoming, I suspect it has to do with ordering.

Comment by Andrew Eisenberg [ 30/May/11 ]

Great. So, I guess this was m2e's problem/regression, and not groovy-eclipse's?

Comment by Benson Margulies [ 30/May/11 ]

As of when you coded it, there were parameters in the extension point to control order. They've been removed. It looks to me as if the problem is that this has to run after the core code that adds the java nature, and it isn't. I await further enlightenment from Igor et al.

Comment by Benson Margulies [ 30/May/11 ]

Wheee. Adding a src/test/groovy folder to the test project fixed everything.

I think that's a bug in the code here.

Comment by Benson Margulies [ 30/May/11 ]

This version works.

Comment by Benson Margulies [ 30/May/11 ]

this version is good to go, but the question is, go where? If I were you, I'd just make this the live version, as 0.12 has no future, but you'll have to decide that for yourself.

Comment by Andrew Eisenberg [ 30/May/11 ]

Are you saying that the patch you have already attached is the good one? But, if it will break if the project has no src/test/groovy folder, then that's not good. Is this something to worry about?

Also, I notice that in the patch, it looks like the configurator is only applicable for gmaven 1.3+. Is this intentional? I don't know that much about gmaven, but why not loosen the version restriction?

As for where to put this, I'm guessing that 0.13 will be released along with the Indigo train at the end of June. The problem is that we need to support SpringSource Tool Suite, which (as of 2.6.1) ships with 0.12 of m2eclipse. I'm guessing that future versions of STS will upgrade to 0.13 when it comes out. However, if 0.13 is only compatible with 3.7 and later, then we are in big trouble. I will then need to keep the old version for 3.5/3.6 and make the new version available only for 3.7. I will wait to commit this until Indigo is released at that point I will know more about what is happening with STS.

Comment by Benson Margulies [ 30/May/11 ]

1. the most recently posted copy of the patch is good.

2. When you add a source folder that does not exist, Eclipse 3.6 gets bent out of shape. I'm not sure how m2e-specific it is. Now, this only happens if you put the particular goal (test or not) in the maven config but don't provide the folder. I tried a little experiment with .toFile().exists() and was surprised when the folder that did exist returned false. If you are a more adept Eclipse API person than me, you could go for it.

3. 0.13 is supported on 3.6 and will be supported on 3.6. 0.12 won't be supported once they 'release' 0.13 (renaming it to 0.14 in the process), if I understand recent traffic. So, a 3.6-friendly STS should plan on moving to 0.14. If STS is supposed to work with 'released' stuff, you should be watching m2-dev for the release of 0.14. If STS wants to follow the evolution of this stuff, track 0.13. Some of us might consider it a favor if you published what I've posted in parallel for 0.13 afficionados/masochists.

I can't test with pre-1.3 so I was conservative, feel free to dial it back. I find the state of the gmaven-plugin somewhat disorienting in general.

Comment by Andrew Eisenberg [ 10/Jun/11 ]

Updated patch.

When I get a chance, I will build an update site based on this patch that is compatible with m2e 0.13.

Benson, in general, it is easier to apply multi-project patches that are created from within eclipse and are created with the workspace root.

Comment by Andrew Eisenberg [ 10/Jun/11 ]

Deleted the old patch since it is not applicable any more.

Comment by Andrew Eisenberg [ 26/Jul/11 ]

Definitely fix for 2.5.2.

Comment by Andrew Eisenberg [ 09/Aug/11 ]

Update site is now available here:
http://dist.codehaus.org/groovy/distributions/greclipse/groovy-m2eclipse-new/

Comment by Andrew Eisenberg [ 07/Sep/11 ]

Thanks for your help. The update site from the previous comment is going away. Now, the configurator is available from the standard groovy-eclipse update site, here:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
and here for e3.6:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/





[GRECLIPSE-1067] Compile error (NoClassDefFoundError) at TestForTransformation Created: 28/May/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Lari Hotari Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy-Eclipse version: 2.5.0.xx-20110511-1600-e36-RELEASE , STS 2.6.1 (Linux 32-bit), Sun Java 1.6.0_25 32-bit, Ubuntu Linux 10.04 64-bit


Number of attachments : 0

 Description   

I imported Grails master branch sources to STS 2.6.1 (with Greclipse 2.5.0).

There is a compile problem in grails-plugin-testing which I couldn't solve.

eclipse.buildId=2.6.1.201105041000-RELEASE
java.version=1.6.0_25
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=fi_FI
Framework arguments:  -showlocation -product com.springsource.sts.ide -refresh
Command-line arguments:  -os linux -ws gtk -arch x86 -showlocation -product com.springsource.sts.ide -clean -data /home/lari/workspace-grails -refresh


Error
Sat May 28 08:07:42 EEST 2011
Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".

java.lang.NoClassDefFoundError: grails/test/mixin/web/ControllerUnitTestMixin
	at org.codehaus.groovy.grails.compiler.injection.test.TestForTransformation$1.<init>(TestForTransformation.java:69)
	at org.codehaus.groovy.grails.compiler.injection.test.TestForTransformation.<clinit>(TestForTransformation.java:68)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at java.lang.Class.newInstance0(Class.java:355)
	at java.lang.Class.newInstance(Class.java:308)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:113)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:225)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1111)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:586)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:564)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:541)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.analyseCode(GroovyCompilationUnitDeclaration.java:1963)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:822)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: grails.test.mixin.web.ControllerUnitTestMixin
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 19 more
Error
Sat May 28 08:07:42 EEST 2011
Errors running builder 'Java Builder' on project 'grails-plugin-testing'.

java.lang.NoClassDefFoundError: grails/test/mixin/web/ControllerUnitTestMixin
	at org.codehaus.groovy.grails.compiler.injection.test.TestForTransformation$1.<init>(TestForTransformation.java:69)
	at org.codehaus.groovy.grails.compiler.injection.test.TestForTransformation.<clinit>(TestForTransformation.java:68)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at java.lang.Class.newInstance0(Class.java:355)
	at java.lang.Class.newInstance(Class.java:308)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:113)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:225)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1111)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:586)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:564)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:541)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.analyseCode(GroovyCompilationUnitDeclaration.java:1963)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:822)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: grails.test.mixin.web.ControllerUnitTestMixin
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 19 more

Reproducing problem:

Steps to get grails sources to imported to STS and to fix other compilation problems before the problem shows up:

  • Checkout grails source from git
  • run "./gradlew eclipse" to generate eclipse .project/.classpath files
  • import all grails sub projects to STS workspace
  • Fix grails-scripts/.project & .classpath files (../scripts isn't allowed as source folder, link to ../scripts):

This added a linkedResources to grails-scripts/.project (last element in projectDescription)

        <linkedResources>
                <link>
                        <name>scripts</name>
                        <type>2</type>
                        <location>/home/lari/workspace-grails/grails-core/scripts</location>
                </link>
        </linkedResources>

in grails-scripts/.classpath fix <classpathentry kind="src" path="scripts"/> (uses linkedResources)

Other compile problems:

  • add <classpathentry kind="lib" path="/home/lari/.gradle/cache/javax.servlet.jsp/jsp-api/jars/jsp-api-2.1.jar" sourcepath="/home/lari/.gradle/cache/javax.servlet.jsp/jsp-api/sources/jsp-api-2.1-sources.jar"/> to grails-web/.classpath
  • add <classpathentry kind="lib" path="/opt/grails-1.4.0.M1/lib/com.springsource.springloaded/springloaded-core/jars/springloaded-core-0.8.0.RELEASE.jar"/> to grails-core/.classpath
  • Now do a clean build
  • The only build problem is caused by the "java.lang.NoClassDefFoundError: grails/test/mixin/web/ControllerUnitTestMixin" error compiling grails-plugin-testing/src/main/groovy/grails/test/mixin/web/FiltersUnitTestMixin.groovy file


 Comments   
Comment by Andy Clement [ 28/May/11 ]

wonder what's changed recently.... I was able to build it in STS a couple of weeks ago.

Comment by Andy Clement [ 30/May/11 ]

These issues all occur because grails-core has now started to break the groovy-eclipse rules again. As per:
http://groovy.codehaus.org/Eclipse+Plugin+2.0.0+FAQ#EclipsePlugin2.0.0FAQ-Q.DoesitsupportcustomASTtransformations%3F

you can't use transforms with groovy dependencies in the same project in which they are defined. I'll discuss with Graeme what he wants to do about it.

Comment by Lari Hotari [ 03/Jun/11 ]

Thanks for the information. I removed "src/test/groovy" from the source paths of the grails-plugin-testing project and now the project compiles.

Comment by Andrew Eisenberg [ 25/Jul/11 ]

It looks like the problem here is fixed. So, I am resolving this issue, but please reopen if you are still having a problem compiling.





[GRECLIPSE-1066] Renaming a Service class makes references to service methods underlined Created: 26/May/11  Updated: 26/May/11  Resolved: 26/May/11

Status: Closed
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.0Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Kris De Volder Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This happens despite of also updating references to the service in accordance with the new name.

Adding a white space change to the service class and saving sometimes but not always fixes the problem.



 Comments   
Comment by Kris De Volder [ 26/May/11 ]

Closing: Wrong Jira tracker...
Raised it also in STS tracker.





[GRECLIPSE-1065] You have managed to deploy a snapshot to central Created: 26/May/11  Updated: 18/Aug/11  Resolved: 27/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: None
Fix Version/s: 2.5.1Release

Type: Bug Priority: Critical
Reporter: Anders Hammar Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Maven central


Number of attachments : 0

 Description   

Snapshots aren't supposed to exist at Maven central, but somehow you've managed to get 2.5.1-SNAPSHOT synced to central:
http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-eclipse-compiler/2.5.1-SNAPSHOT/

Very bad!

A possible reason for this is that you're not using the Nexus instance at Codehaus, but the old Maven repo. You should switch to the Nexus instance asap!



 Comments   
Comment by Andrew Eisenberg [ 26/May/11 ]

Apologies for that. Any way to remove the snapshot from maven central?

I'll switch to the nexus instance. Is there any documentation for this explaining exactly what I should and should not be doing? I am new to maven as well as maven deployment and so I wasn't aware of these restrictions and conventions.

Comment by Andrew Eisenberg [ 26/May/11 ]

I found this:
http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usage+Guide

I will delete the snapshots from the codehaus repository that is synced to maven, but still not sure how to delete from maven.

Comment by Juven Xu [ 26/May/11 ]

I will delete them from maven central

Comment by Andrew Eisenberg [ 26/May/11 ]

Thanks Juven.

Two more snapshots made it over to central:
http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-eclipse-batch/1.7.10-SNAPSHOT/
http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-eclipse-batch/1.8.0-SNAPSHOT-02/

Comment by Juven Xu [ 27/May/11 ]

these snapshots are deleted from central, you can close this ticket now

Comment by Anders Hammar [ 27/May/11 ]

Andrew,

the docs for switching to the Nexus instance is here:
http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usage+Guide

Juven will help you when you've created the appropriate jira ticket.

Btw, thanks for taking this seriously and acting!

Comment by Andrew Eisenberg [ 27/May/11 ]

Thanks for helping me out here and for helping me figure out what I should be doing.

Comment by Alex McManus [ 18/Aug/11 ]

Is there any chance that you can fix the metadata on central for these artifacts? If I look at the maven-metadata-central.xml that gets copied into my local repository, it has the following:

<?xml version="1.0" encoding="UTF-8"?>

<metadata>
  <groupId>org.codehaus.groovy</groupId>
  <artifactId>groovy-eclipse-batch</artifactId>
  <versioning>
    <latest>1.8.0-03</latest>
    <release>1.8.0-03</release>
    <versions>
      <version>1.7.10-SNAPSHOT</version>
      <version>1.7.10-01</version>
      <version>1.7.10-02</version>
      <version>1.8.0-SNAPSHOT-02</version>
      <version>1.8.0-01</version>
      <version>1.8.0-02</version>
      <version>1.8.0-03</version>
    </versions>
    <lastUpdated>20110527175716</lastUpdated>
  </versioning>
</metadata>

You can see that it still lists the SNAPSHOTS. I'm using Maven 2.0.11, and whenever I use groovy-eclipse-compiler which has a version-range dependency on groovy-eclipse-batch, it tries to download 1.8.0-SNAPSHOT-02 (I have no idea why). I can add an explicit dependency to the correct version of groovy-eclipse-batch, but it still insists on trying to download version 1.8.0-SNAPSHOT-02. When it doesn't find it, it carries on and the build works, but it still adds a few seconds delay every time I compile the project...

Thanks, Alex.

Comment by Andrew Eisenberg [ 18/Aug/11 ]

That's annoying. I'll see what I can do.

Comment by Anders Hammar [ 18/Aug/11 ]

These SNAPSHOT versions don't exist, but the metadata at central say they exist. The way to get this fixed is to file a ticket at
https://issues.sonatype.org/browse/MVNCENTRAL

Comment by Andrew Eisenberg [ 18/Aug/11 ]

Already done:
https://issues.sonatype.org/browse/MVNCENTRAL-97

Waiting to hear back.





[parser] Better parser recovery (GRECLIPSE-468)

[GRECLIPSE-1064] [parser] Code completion inside of parens is broken Created: 25/May/11  Updated: 01/Nov/11  Resolved: 01/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: 2.5.0Release
Fix Version/s: 2.6.0.Release

Type: Sub-task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This code will break the parser and content-assist will not work

String str = "hello"
println(str./* ctrl + space */ )


 Comments   
Comment by Andy Clement [ 01/Jun/11 ]

this works on 1.8, fails on 1.7

Comment by Andy Clement [ 01/Nov/11 ]

not retrofitting recovery into 1.7, this works on 1.8





[GRECLIPSE-1063] Invalid completion proposal for upper-case property Created: 25/May/11  Updated: 10/Jun/11  Resolved: 10/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

From the mailing list:

 class A {
   int FOO = 1
   static int BAR = 2
 }
 println new A().// ctrl + space

The completion proposal "fOO" is suggested, but shouldn't be.



 Comments   
Comment by Andrew Eisenberg [ 10/Jun/11 ]

This is already fixed. Just closing now.





[GRECLIPSE-1062] AST transformations cause errors in eclipse Created: 20/May/11  Updated: 04/Jul/11  Resolved: 04/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Travis Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

AST transformations like @ToString are causing the following error at random.

Description Resource Path Location Type
Groovy:Not an ASTTransformation: org.codehaus.groovy.transform.ToStringASTTransformation declared by groovy.transform.ToString KimAttributeBo.groovy /rice-kim-impl/src/main/groovy/org/kuali/rice/kim/impl/common/attribute line 0 Java Problem

This problem goes away after doing a clean but then comes right back when editing the file with the ast annotation. I have confirmed that the groovy-eclipse plugin is set to compile at version 1.8.

What's also interesting is some of our devs claim that switching the compiler to 1.7, restarting eclipse, then back to 1.8, restarting eclipse fixes the problem for a while - but then comes back.



 Comments   
Comment by Andy Clement [ 25/May/11 ]

without an ability to recreate it, going to be quite tricky to address. I've put some diagnostics in today so that when this occurs we can see the classloaders involved at the decision point that leads to the error. These should come out on the end of the message you are already seeing. The dev build should be out in a few hours.

Comment by Andy Clement [ 25/May/11 ]

build with extra debug is out

Comment by Jeff Maxwell [ 06/Jun/11 ]

Just a note same problem occurs with @EqualsAndHashCode





[GRECLIPSE-1061] Create an official release of the groovy-eclipse-compiler for maven. Created: 20/May/11  Updated: 28/Jun/11  Resolved: 28/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

For 2.5.1, we should release the groovy-eclipse-compiler for maven in a non-snapshot form. We need to create a CI build for this, as well as an automated way of getting the artifacts onto the codehaus repository and maven central.

Furthermore, we need to support both groovy 1.7 and 1.8. There will need to be one build for each.



 Comments   
Comment by Andrew Eisenberg [ 20/May/11 ]

Yay! I have just successfully published to the codehaus maven repo. Still lots more work to do, but this is a major step.

Comment by Andrew Eisenberg [ 01/Jun/11 ]

The milestone is now available in maven central.

Comment by Andrew Eisenberg [ 28/Jun/11 ]

The release is ready. Just waiting for it to be staged into the nexus repo at codehaus.





[GRECLIPSE-1060] Support a groovier way of handling closure parameters in method calls Created: 19/May/11  Updated: 19/May/11  Resolved: 19/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When performing content assist and the last parameter is a closure, the closure should be specified outside of the parens, just like in canonical groovy.

Eg, content assist should provide something like this:

use(null) { }

and

each { }


 Comments   
Comment by Andrew Eisenberg [ 19/May/11 ]

Will be available after I commit.





[GRECLIPSE-1059] support $/ /$ strings Created: 19/May/11  Updated: 19/May/11  Resolved: 19/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There is a new way to specify multiline strings in Groovy 1.8 using $/ and /$. Groovy-Eclipse should support this.



 Comments   
Comment by Andrew Eisenberg [ 19/May/11 ]

About to commit the fix.





[GRECLIPSE-1058] @Delegate never worked for me Created: 17/May/11  Updated: 09/Jun/11  Resolved: 09/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.0Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Johann Burkard Assignee: Andy Clement
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Xubuntu Linux, Groovy-Eclipse plugin Version: 2.1.0.xx-20110510-1000-e35-release


Testcase included: yes
Number of attachments : 0

 Description   

@Delegate annotations never worked for me. Here's an example:

package com.eaio.concurrent

import groovy.lang.Delegate
import groovy.transform.Synchronized

import java.util.Collection
import java.util.Iterator
import java.util.concurrent.BlockingQueue
import java.util.concurrent.ThreadPoolExecutor
import java.util.concurrent.TimeUnit

class DynamicBlockingQueue {
    
    @Delegate
    BlockingQueue queue
    
    ThreadPoolExecutor executor
    
    DynamicBlockingQueue(BlockingQueue queue = null) {
        this.queue = queue
    }

    @Synchronized
    boolean offer(def e) {
        !executor || executor.poolSize == executor.maximumPoolSize ? queue.offer(e) : false
    }

}

The error message is: Groovy:Can't have an abstract method in a non-abstract class. The class 'com.eaio.concurrent.DynamicBlockingQueue' must be declared abstract or the method 'java.lang.Object element()' must be implemented.

The class compiles fine using GMaven (though only with certain Groovy versions).



 Comments   
Comment by Andy Clement [ 17/May/11 ]

thanks for the testcase

Comment by Andy Clement [ 17/May/11 ]

I presume it works for you with other samples like the Photo one from the page http://docs.codehaus.org/display/GROOVY/Delegate+transformation

Comment by Johann Burkard [ 17/May/11 ]

Well, it works with the 2.5.0 version from groovy.codehaus.org. I guess I'll have to upgrade then.

Close this bug if you want.

Comment by Andrew Eisenberg [ 09/Jun/11 ]

Resolving this issue as cannot reproduce. Please re-open if you see problems again.





[GRECLIPSE-1057] Java formatting for indentation not being followed when tab policy is 'mixed' Created: 13/May/11  Updated: 08/Jun/11  Resolved: 08/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.1.2Release, 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Minor
Reporter: Roger Talkov Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, eclipse 3.6.2


Testcase included: yes
Number of attachments : 0

 Description   

In Java->Code Style->Formatter, I set the indentation size to 2 and tab size to 8 and the tab policy to mixed. If I format Groovy code or enter Groovy code where indentation will take affect, the code is indented by 8 spaces. For java code it works correctly and indents by 2 spaces. If I change the tab policy to spaces the indentation works correctly on Groovy code, it indents by 2 spaces.
An example of code entry would be to enter an if statement followed by an opening curly brace and then the <ENTER> key, the next line will indent by 8 spaces in mixed tab mode



 Comments   
Comment by Kris De Volder [ 08/Jun/11 ]

I committed a fix. and a couple of regression tests, for the formatter and autoindenter.





[GRECLIPSE-1056] content assist failure when invoking after a comment Created: 13/May/11  Updated: 13/May/11  Resolved: 13/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following code:

def xxxxx
if(true) { //

}

Invoke content assist on the blank line in the if statement. There is no xxxxx proposal as you would expect. The reason is the org.codehaus.groovy.eclipse.core.util.ExpressionFinder class. Inside the findForCompletion method, the resulting token includes the comment, but it should not.



 Comments   
Comment by Andrew Eisenberg [ 13/May/11 ]

OK. I think I fixed it, but I need to be careful since this could have consequences elsewhere.

Comment by Andrew Eisenberg [ 13/May/11 ]

OK. Resolving this as fixed since I have created some test cases that are now working. There may be some other problems, but I am feeling more confident about this so probably nothing big.





[GRECLIPSE-1055] Remove all hardwired paths from launch configurations Created: 11/May/11  Updated: 10/Jun/11  Resolved: 10/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
is depended upon by GRECLIPSE-482 GroovyWS script doesnt work when run ... Resolved
Number of attachments : 0

 Description   

When generating launch configurations, it is necessary to include components from inside of the currently installed org.codehaus.groovy bundle (such as the groovy-starter.conf file). Currently, we use hard wired fully qualified paths for this. However, is bad for at least two reasons:

  1. these launch configurations cannot be shared between users
  2. after an upgrade of groovy-eclipse, the files pointed to by the launch config may no longer be there.

The solution is to create a launch configuration variable that points to the currently used org.codehaus.groovy bundle in the installation folder and use that variable instead of hard-wired paths. I'm not entirely sure if it is possible to create custom launch config variables and if it isn't then we will need to look at some other solution.



 Comments   
Comment by Andrew Eisenberg [ 10/Jun/11 ]

Now fixed. I had to create a new variable resolver for Groovy home to find a file system agnostic way of getting the currently active groovy bundle.





[GRECLIPSE-1054] Renaming private fields, methods, and all properties will not update references in non-working copies Created: 10/May/11  Updated: 10/Jun/11  Resolved: 10/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: None
Fix Version/s: 2.5.1Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
  • In Foo.groovy
    class Foo {
      def foo
    }
    
  • In Other.groovy
    new Foo().foo
    
  • Close and save Other.groovy
  • Rename foo

Reference to foo in Other.groovy is not updated. This is because org.eclipse.jdt.internal.corext.refactoring.RefactoringScopeFactory.create(IJavaElement, boolean, boolean) ignores otehr compilation units if the target to rename if private (and in this case, foo is a property, so it is private).

Potential solution: in org.eclipse.jdt.core.search.SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor), add a hook into language support that will check the search pattern and requestor to see of the search scope should be expanded.

Here are the criteria for expanding the search scope:

  1. pattern.focus is a private field or method in a groovy compilation unit
  2. requestor is of type (or a subtype of) org.eclipse.jdt.internal.corext.refactoring.CollectingSearchRequestor.

If this matches, then create a search scope that encompasses the entire project and all depending projects.

This solution is more than a little ugly, but I don't see any other way of proceeding.



 Comments   
Comment by Andrew Eisenberg [ 10/Jun/11 ]

OK. I have something that appears to be working now. However, I am not sure of something. It is possible that a private field in a Java class is legally accessed in a groovy class. I should probably expand the refactoring search scope for Java classes as well if they are in groovy projects. Originally, I did not want to change behavior for Java files, but I may have to.

Comment by Andrew Eisenberg [ 10/Jun/11 ]

I think I will expand the search scope for private declarations defined in Java. The downside is that rename refactorings will take longer for Java classes defined in Groovy projects, but the benefit is correctness.

Comment by Andrew Eisenberg [ 10/Jun/11 ]

Now fixed on both the 3.6 and 3.7 branches.





[GRECLIPSE-1053] Can't undo rename type refactoring when invoked from outside of editor Created: 10/May/11  Updated: 09/Jun/11  Resolved: 09/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.2Release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Kris De Volder
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Create a groovy type in a file with the same name and code that looks like this:

class BadClass {
  BadClsss s = null
}

Do rename refactoring from the package explorer on the type. Try to undo, but it is not possible.



 Comments   
Comment by Kris De Volder [ 20/May/11 ]

I'll have a look into what is going on here... fixing it is a prerequisite to getting the undo for multi-artifact rename in Grails to work as well.

Comment by Kris De Volder [ 20/May/11 ]

Hmmm... it appears this is actually an Eclipse JDT bug.

I am trying to do this in a brand new Eclipse 3.6.2 with nothing extra installed in a Java project with a Java class that looks like the example...

And I get the exact same error.

In case it matters... my class was not in the default package.

package foop;

public class Bioloz {

	Bioloz me = null;
	
}
Comment by Kris De Volder [ 20/May/11 ]

Raised a bug against JDT:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=346770

Comment by Kris De Volder [ 09/Jun/11 ]

Closing, this isn't Greclipse bug.





[GRECLIPSE-1051] NPE in Refresh DSLD Created: 08/May/11  Updated: 30/Sep/12  Resolved: 31/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: DSL Support
Affects Version/s: 2.5.0Release
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Francois Rey Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Arch Linux 64 bit
Eclipse IDE for Java Developers
Version: Helios Service Release 2
Build id: 20110218-0911
Groovy-Eclipse Feature 2.1.3.xx-20110505-1800-e36


Attachments: JPEG File refresh-dsld-npe-screenshot1.jpeg     Zip Archive TestGroovyProject.zip    
Number of attachments : 2

 Description   

This error occured only once after restarting eclipse after upgrading to Groovy-Eclipse Feature 2.1.3.xx-20110505-1800-e36.
I have not seen it since. Maybe it's already fixed, maybe it's gone after eclipse -clean.
The TestGroovyProject was just opened, none of its file was opened. I was in fact in the PHP perspective.
I can attach the project if needed. It does not have much in it, could it be linked to its gradle build script?

=== eclipse log entry ====
eclipse.buildId=M20110210-1200
java.version=1.6.0_25
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.java.product

Error
Sun May 08 09:57:25 CEST 2011
An internal error occurred during: "Refresh DSLD scripts for TestGroovyProject".

java.lang.NullPointerException
at org.eclipse.core.internal.preferences.EclipsePreferences.removePreferenceChangeListener(EclipsePreferences.java:953)
at org.eclipse.jdt.internal.core.JavaProject.getEclipsePreferences(JavaProject.java:1482)
at org.eclipse.jdt.internal.core.JavaProject.getOption(JavaProject.java:1624)
at org.eclipse.jdt.internal.core.ClasspathEntry.validateClasspathEntry(ClasspathEntry.java:1985)
at org.eclipse.jdt.internal.core.ClasspathEntry.validateClasspathEntry(ClasspathEntry.java:1815)
at org.eclipse.jdt.internal.core.ClasspathValidation.validate(ClasspathValidation.java:68)
at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:51)
at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
at org.eclipse.jdt.internal.core.JavaModelManager$9.run(JavaModelManager.java:2644)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2660)
at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1846)
at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1920)
at org.eclipse.jdt.internal.core.JavaProject.buildStructure(JavaProject.java:442)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:252)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:238)
at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:193)
at org.eclipse.jdt.internal.core.JavaProject.getPackageFragmentRoots(JavaProject.java:1808)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findDSLDsInLibraries(RefreshDSLDJob.java:81)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findFiles(RefreshDSLDJob.java:68)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:185)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)



 Comments   
Comment by Andrew Eisenberg [ 08/May/11 ]

This looks like a race condition in org.eclipse.equinox.preferences caused the NPE. Here's the relevant code:


	public void removePreferenceChangeListener(IPreferenceChangeListener listener) {
		checkRemoved();
		if (preferenceChangeListeners == null)
			return;
		preferenceChangeListeners.remove(listener);
		if (preferenceChangeListeners.size() == 0)
			preferenceChangeListeners = null;
		if (DEBUG_PREFERENCE_GENERAL)
			PrefsMessages.message("Removed preference property change listener: " + listener + " from: " + absolutePath()); //$NON-NLS-1$ //$NON-NLS-2$
	}

Line 953 (where the NPE occurred is the second if statement and the condition is: preferenceChangeListeners.size() == 0. So apparently, preferenceChangeListeners is not null on the previous line, but it is null afterwards. It therefore appears that the thread went to sleep on line 952. The thread was preempted by another thread that set preferenceChangeListeners to null.

Other than the error dialog, did you notice any errant behavior? Have you seen this exception more than once?

Comment by Francois Rey [ 08/May/11 ]

I have not seen this exception since and I kept working afterwards but soon restarted because of another update.
Interesting, how can we fix such race condition in a more general case in Eclipse (I may have a similar case on my plate)

Comment by Andrew Eisenberg [ 08/May/11 ]

I can't find references to any other similar problem when I googled for it. But, this stack entry: org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2660) is reached only during initial startup. Things may behave differently if the job grabs that initiates the call grabs the root scheduling rule.

In the case of this bug report that would be the RefreshDSLDJob), but it wouldn't be appropriate since grabbing the root scheduling rule would essentially lock the workspace for all writes (eg- saves, builds, launches, and many other operations would have to wait until this job is completed before they could start).

Comment by Andrew Eisenberg [ 30/May/11 ]

Have you seen this exception again? I can't reproduce myself and I can't see any obvious way to prevent a race condition here (if one exists). If you haven't seen this again, I will close the issue, but feel free to re-open if you can reproduce.

Comment by Francois Rey [ 31/May/11 ]

No I have not. Will certainly reopen if needed. Thanks.

Comment by Andrew Eisenberg [ 31/May/11 ]

Closing for now.

Comment by Gerd Aschemann [ 30/Sep/12 ]

I see the same message (I think at any time, I try to start Eclipse - which is usually running for weeks ...):

eclipse.buildId=M20120208-0800
java.version=1.6.0_35
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product -keyring /Users/ascheman/.eclipse_keyring -showlocation
Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/ascheman/.eclipse_keyring -showlocation

...

!ENTRY org.eclipse.core.jobs 4 2 2012-09-30 08:46:20.841
!MESSAGE An internal error occurred during: "Refresh DSLD scripts".
!STACK 0
java.lang.NullPointerException
at org.eclipse.m2e.jdt.internal.MavenClasspathContainerInitializer.initialize(MavenClasspathContainerInitializer.java:48)
at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:2851)
at org.eclipse.jdt.internal.core.JavaModelManager$9.run(JavaModelManager.java:2757)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2797)
at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1875)
at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:3128)
at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2698)
at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2862)
at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1967)
at org.eclipse.jdt.internal.core.JavaProject.buildStructure(JavaProject.java:466)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:196)
at org.eclipse.jdt.internal.core.JavaProject.getPackageFragmentRoots(JavaProject.java:1855)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor$1.run(RefreshDSLDJob.java:199)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.getFragmentRoots(RefreshDSLDJob.java:197)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findDSLDsInLibraries(RefreshDSLDJob.java:107)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob$DSLDResourceVisitor.findFiles(RefreshDSLDJob.java:97)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.refreshProject(RefreshDSLDJob.java:320)
at org.codehaus.groovy.eclipse.dsl.RefreshDSLDJob.run(RefreshDSLDJob.java:268)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Comment by Andrew Eisenberg [ 30/Sep/12 ]

This is a separate issue. Could you please raise this in a new bug?

Looks like refresh dsld job is being run so early that m2e has not yet been initialized.





[GRECLIPSE-1050] IllegalArgumentException when attempting ctrl+click navigation Created: 06/May/11  Updated: 10/May/11  Resolved: 10/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Attempting ctrl click on something:

java.lang.IllegalArgumentException: java.lang.Class[]<java.lang.Object<T>>
at org.eclipse.jdt.core.Signature.createCharArrayTypeSignature(Signature.java:635)
at org.eclipse.jdt.core.Signature.createTypeSignature(Signature.java:607)
at org.eclipse.jdt.core.Signature.createTypeSignature(Signature.java:899)
at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createUniqueKeyForResolvedClass(CodeSelectRequestor.java:383)
at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createUniqueKeyForClass(CodeSelectRequestor.java:395)
at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createUniqueKeyForMethod(CodeSelectRequestor.java:358)
at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createUniqueKey(CodeSelectRequestor.java:342)
at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.resolveRequestedElement(CodeSelectRequestor.java:242)
at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.acceptASTNode(CodeSelectRequestor.java:132)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleRequestor(TypeInferencingVisitorWithRequestor.java:1530)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleExpression(TypeInferencingVisitorWithRequestor.java:767)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstantExpression(TypeInferencingVisitorWithRequestor.java:1201)
at org.codehaus.groovy.ast.expr.ConstantExpression.visit(ConstantExpression.java:73)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1276)
at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBinaryExpression(TypeInferencingVisitorWithRequestor.java:923)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitDeclarationExpression(TypeInferencingVisitorWithRequestor.java:1220)
at org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:85)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:209)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1071)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstructorOrMethod(TypeInferencingVisitorWithRequestor.java:645)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:391)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:237)
at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:192)
at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectHelper.select(CodeSelectHelper.java:57)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:503)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:495)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect_aroundBody0(GroovyCompilationUnit.java:490)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect_aroundBody1$advice(GroovyCompilationUnit.java:312)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:1)
at org.eclipse.jdt.internal.ui.javaeditor.JavaElementHyperlinkDetector.detectHyperlinks(JavaElementHyperlinkDetector.java:67)
at org.eclipse.ui.texteditor.HyperlinkDetectorRegistry$HyperlinkDetectorDelegate.detectHyperlinks(HyperlinkDetectorRegistry.java:80)
at org.eclipse.jface.text.hyperlink.HyperlinkManager.findHyperlinks(HyperlinkManager.java:276)
at org.eclipse.jface.text.hyperlink.HyperlinkManager.mouseMove(HyperlinkManager.java:452)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:205)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3783)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1398)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1383)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1195)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3629)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3284)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)

i dont have a test program



 Comments   
Comment by Andrew Eisenberg [ 06/May/11 ]

This one will be pretty hard to fix without being able to reproduce. Perhaps I can add some code so a better error message will be spit out.

It looks like the target type has a name java.lang.Class[]<java.lang.Object<T>>. Working on anything like that?

Comment by Andy Clement [ 06/May/11 ]

ClassHelper.make(List.class) clicking on 'make'

Comment by Andrew Eisenberg [ 06/May/11 ]

Thanks...I got it now.

Comment by Andrew Eisenberg [ 06/May/11 ]

OK. I have a fix for this internally. The problem is with the way arrays of generic type signatures are being constructed. The '[]' was coming before the '<','>' instead of after.

But this has uncovered a different problem, which I am not sure how to fix yet. Currently, we do not distinguish between type arguments and type parameters when hovering. What I mean is: List<E> 'E' is a parameter, and List<String> is an argument.

Also, still need to create some tests for this, so leaving open for now.

Comment by Andrew Eisenberg [ 10/May/11 ]

Fix is now committed with regression tests.





[GRECLIPSE-1049] Inline rename of type fails if the name is changed to become the same as its compilation unit Created: 05/May/11  Updated: 03/Jan/12  Resolved: 03/Jan/12

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.2Release
Fix Version/s: 2.6.1.Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If a Groovy class has a different name than its compilation unit, and you rename it (using rename refactoring from the editor) to the same name, then it throws a "Fatal error" in the refactoring.

Example:
file "Boohoo.groovy"

class Baahaa {
}

Rename class Baahaa to "Boohoo".



 Comments   
Comment by Andrew Eisenberg [ 28/Sep/11 ]

Seems like something we should fix for 2.6.0.

Comment by Andrew Eisenberg [ 01/Dec/11 ]

I don't think there's an easy solution here. All the checks for this are bound up in jdt.ui code, which is something that we don't patch. Maybe there is some way that I can spin this as a JDT bug and get this fixed in JDT. Let me look.

Comment by Andrew Eisenberg [ 01/Dec/11 ]

Raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=365380

Comment by Andrew Eisenberg [ 02/Dec/11 ]

Moving to 2.6.1 release. Waiting for patch to be committed to JDT UI project.

Comment by Andrew Eisenberg [ 03/Jan/12 ]

Fixed in JDT, but may not be backported to 3.7.2. Hopefully, we won't have to wait for Juno for a fix on this.





[parser] Better parser recovery (GRECLIPSE-468)

[GRECLIPSE-1048] [parser] Content Assist not working reliably when defining method parameters Created: 05/May/11  Updated: 01/Nov/11  Resolved: 01/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: 2.1.2Release
Fix Version/s: 2.6.0.Release

Type: Sub-task Priority: Major
Reporter: Stefan Sieber Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File ContentAssistError.png     File TextCompletionTest.groovy    
Number of attachments : 2

 Description   

When using Content assist when defining the parameters of a method ("println(var.|)"), content assist only shows generic entries (see attached screenshot).

After typing the first character after the dot (i.e. println(var.b|), content assist usually works as expected.

The code of the example class is also attached. I'll be happy to provide more information if needed

Versions:
Greclipse: 2.1.3.xx-20110502-1000-e36
Eclipse: Helios Service Release 1 (20100917-0705)



 Comments   
Comment by Andrew Eisenberg [ 05/May/11 ]

You are seeing this problem because of the problems with the underlying antlr parser. When you have something like print(var.) the parser does not know how to handle this and it throws an exception. We tend to fix these problems as they come up and so we will add this one to the list.

Comment by Andy Clement [ 01/Nov/11 ]

this scenario works now, at least on 1.8 - code assist is fine. We aren't retrofitting recovery to 1.7 now.





[GRECLIPSE-1047] "Unreachable catch block" when java code calls groovy code Created: 04/May/11  Updated: 04/May/11  Resolved: 04/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

From the STS forum: http://forum.springsource.org/showthread.php?t=108712

I have this annoying situation in my IDE (STS 2.6.0.RELEASE); we have a java class that invokes methods on a groovy class. My IDE indicates, on the catch block, that the catch is unreachable.

I've managed to recreate it easily enough with the following:

Groovy code:

import javax.mail.MessagingException

public interface CanThrowException {
  void thisCanThrowException() throws MessagingException
}

Java code:

import javax.mail.MessagingException;

class ShouldCatchException {
  private CanThrowException thing;
  
  public void doIt() {
    try {
      thing.thisCanThrowException();
    } catch( MessagingException e ) {
      System.out.println("Did we catch it?");
    }
  }
}

The interesting thing is that if the catch block is removed, the complain then becomes that the MessagingException isn't caught, so a catch block should be added. 'javap' shows the interface was, indeed, constructed saying that the exception is thrown.

Via the command line, the build succeeds just fine (no surprise), so it's definitely more of an annoyance than anything else.

Something is not quite right ...

Suggestions? Bug (where do I file it?)?

Thanks!

john

I have been able to reproduce this in my own workspace.



 Comments   
Comment by Andrew Eisenberg [ 04/May/11 ]

Ahhh...this is interesting and I should have looked for this originally.

With the try-catch block in place, the error is a reconciling error (ie- does not appear in problems view). But with the try-catch removed, the error is a compilation error (ie- in the problems view).

What this means is that during reconciling, the groovy method is not declaring its thrown exceptions properly.

Comment by Andy Clement [ 04/May/11 ]

fixed, for constructors too. I was also seeing it as a compile error with the try catch in place, not just reconciling.





[parser] Better parser recovery (GRECLIPSE-468)

[GRECLIPSE-1046] [parser] Code assistant does not work inside if condition Created: 03/May/11  Updated: 02/Nov/11  Resolved: 02/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: 2.1.2Release
Fix Version/s: 2.6.0.Release

Type: Sub-task Priority: Major
Reporter: Lizhang Qin Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any env


Number of attachments : 0

 Description   

A simple example

    File f = new File('c:\\test')
    f.isD (press ctrl-space) here, 

it will show isDirectory() candidate.

But when the same thing within a if condition (or other condition)

    if (f.isD press ctrl-space

it shows nothing, and

    if (f. press ctrl-space)

editor only show the Object's methods / properties.

Can we improve this? I think this could be common scenario people use (hope to get code assistant)

Thanks



 Comments   
Comment by Andrew Eisenberg [ 03/May/11 ]

This is a parser recovery problem. The Groovy compiler is based on an antlr parser, which does not handle invalid code very well.

So, when you type:

if (f.) { }

The parser cannot handle this input and it breaks.

Similarly, with

if (f.

That is why you are not seeing helpful content assist here. We tend to fix the parser recovery problems as they come up. And we may be able to do something about this problem.

Comment by Andy Clement [ 02/Nov/11 ]

All fixed in 1.8.

This case was ok:

if (f.) {}

because we have previously added recovery for the trailing dot situation.

What I've just fixed is support for this case:

if (f.)

where the 'then' clause is missing

and

if (f.

where the closing paren is also missing.

In all these cases you now see isDirectory() as a proposed completion (and the other file methods)





[GRECLIPSE-1045] NoClassDefFoundError: org/codehaus/groovy/ast/stmt/LoopingStatement Created: 03/May/11  Updated: 04/May/11  Resolved: 03/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Daniel Serodio Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Springsource Tool Suite 2.6.0 on Mac OS 10.6.7


Attachments: Zip Archive GroovyTest.zip    
Number of attachments : 1

 Description   

When I open Eclipse and it refreshes a "hello world" Groovy project, the following message is logged:

!ENTRY org.eclipse.core.resources 4 2 2011-05-03 15:45:20.963
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
!STACK 0
java.lang.NoClassDefFoundError: org/codehaus/groovy/ast/stmt/LoopingStatement
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.newInstance0(Class.java:326)
at java.lang.Class.newInstance(Class.java:308)
at org.codehaus.groovy.transform.ASTTransformationVisitor.addPhaseOperationsForGlobalTransforms(ASTTransformationVisitor.java:380)
at org.codehaus.groovy.transform.ASTTransformationVisitor.doAddGlobalTransforms(ASTTransformationVisitor.java:347)
at org.codehaus.groovy.transform.ASTTransformationVisitor.addGlobalTransforms(ASTTransformationVisitor.java:240)
at org.codehaus.groovy.transform.ASTTransformationVisitor.addPhaseOperations(ASTTransformationVisitor.java:203)
at org.codehaus.groovy.control.CompilationUnit.<init>(CompilationUnit.java:208)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.<init>(GroovyParser.java:250)
at org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.<init>(MultiplexingParser.java:38)
at org.codehaus.jdt.groovy.integration.internal.GroovyLanguageSupport.getParser(GroovyLanguageSupport.java:85)
at org.codehaus.jdt.groovy.integration.LanguageSupportFactory.getParser(LanguageSupportFactory.java:47)
at org.eclipse.jdt.internal.compiler.Compiler.initializeParser(Compiler.java:737)
at org.eclipse.jdt.internal.compiler.Compiler.<init>(Compiler.java:294)
at org.eclipse.jdt.internal.compiler.Compiler.<init>(Compiler.java:204)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.newCompiler(AbstractImageBuilder.java:580)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.<init>(AbstractImageBuilder.java:128)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.<init>(BatchImageBuilder.java:33)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:256)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:176)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassNotFoundException: org.codehaus.groovy.ast.stmt.LoopingStatement
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 34 more



 Comments   
Comment by Andrew Eisenberg [ 03/May/11 ]

LoopingStatement is a class that is in he 1.8 compiler only. It looks like you are using the 1.7 compiler in your workspace, but your ast transform requires 1.8. See here http://docs.codehaus.org/display/GROOVY/Compiler+Switching+within+Groovy-Eclipse for more information about compiler switching.

Comment by Daniel Serodio [ 03/May/11 ]

I'm not using any AST transforms. This project contains only HelloGroovy.groovy which is:

def slurper = new XmlSlurper().parse(".project")
println slurper

Comment by Daniel Serodio [ 03/May/11 ]

Project where this error occurs

Comment by Andrew Eisenberg [ 03/May/11 ]

Thanks for the project. I was able to compile and run the project with no problems using Groovy 1.7 as well as Groovy 1.8.

I'm guessing that there is a mismatch in your workspace between the compiler being used to compile your project and the libraries on your project's classpath. Can you attach the following information:

  1. Open Preferences -> Groovy -> Compiler. What is the current version of the compiler being used?
  2. In your project in the package explorer, expend the Groovy Libraries classpath container. Select all of the jar files, right click -> Copy. Paste the jars in here.
  3. Also, open the Groovy Event Console, do a full build of your project and copy the results here. (For information on how to open the console, see here: http://groovy.codehaus.org/Groovy-Eclipse+2.1.2+New+and+Noteworthy#Groovy-Eclipse2.1.2NewandNoteworthy-TimersforASTTransformoperationsnowshowninGroovyEventConsole)
Comment by Daniel Serodio [ 03/May/11 ]

Thanks to your troubleshooting steps, I found the cause of this problem: I had groovypp-0.4.230_1.8.0.jar in ~/.groovy/lib/ which was causing this error. Removing it fixed the problem. I'll try reporting this problem to Groovy++ developers, maybe it can detect it's running under a different version of Groovy and stay away.

Comment by Daniel Serodio [ 03/May/11 ]

Groovy++ was messing up the classpath.

Comment by Alex Tkachman [ 04/May/11 ]

Just for record - Groovy++ didn't mess classpath. Classpath was just set wrongly. There is nothing g++ compiler can do about it





[GRECLIPSE-1044] Groove Code Fomater stops working when using a little bit more "complex" logic in a GString Created: 26/Apr/11  Updated: 26/Apr/11  Resolved: 26/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Formatting
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Konstantinos Kostarellis Assignee: Kris De Volder
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version: 2.7.0.CI-B343 (Groovy-Eclipse Feature 2.1.2.xx-20110310-1500-e36), grails 1.3.7, jvm 1.6.24, kubuntu 10.04.2 LTS


Source ID: formatter GString
Number of attachments : 0

 Description   

I experienced that formatting (Ctrl+Shift+F) stops working when I used a little bit more complex logic in a GString.

Its enough to write a method with code like the following abbreviated example and the formatting stops working for the complete class file.

def FLAVOURS = [all:'.all',tiny:'.tiny',form:'.form']
def a = "Flavour must be in: ${FLAVOURS.collect{it.key}}"

of course the second line is the one that produces the problem.
As soon as this line is commented or removed, formatting works again.

Hope this helps improving the formatter and is not duplicating a similar issue.



 Comments   
Comment by Kris De Volder [ 26/Apr/11 ]

Thanks for the bug report. The problem is reproducible, so hopefully won't be too hard to fix.
This error is likely the culprit, will need to debug it a bit to understand why it happens.

java.lang.ArrayIndexOutOfBoundsException: -1
	at java.util.ArrayList.get(ArrayList.java:324)
	at org.codehaus.groovy.eclipse.refactoring.formatter.KlenkDocumentScanner.get(KlenkDocumentScanner.java:159)
	at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyBeautifier.combineClosures(GroovyBeautifier.java:187)
	at org.codehaus.groovy.eclipse.refactoring.formatter.GroovyBeautifier.getBeautifiEdits(GroovyBeautifier.java:71)
	at org.codehaus.groovy.eclipse.refactoring.formatter.DefaultGroovyFormatter.format(DefaultGroovyFormatter.java:155)
	at org.codehaus.groovy.eclipse.refactoring.actions.FormatGroovyAction.run(FormatGroovyAction.java:73)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:278)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:250)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
	at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
	at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3540)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3161)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
Comment by Kris De Volder [ 26/Apr/11 ]

Committed a fix. The problem was because of the closure inside the GString. The formatter got confused because scanner doesn't return tokens "inside" a GString.

I've made it so that it skips formatting closures when it can't find the starting token of the closure where it is expected. This should only happen if the closure is inside a GString.

Kris





[GRECLIPSE-1043] Exception coming from outline view Created: 26/Apr/11  Updated: 26/Apr/11  Resolved: 26/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I am getting this exception when I delete all lines in a script, leaving only classes behind. This is related to GRECLIPSE-1029. This exception is not affecting behavior, but it is annoyingly populating the error log.

Java Model Exception: Java Model Status [AnotherScript [in [Working copy] AnotherScript.groovy [in <default> [in src [in DSLD tests]]]] does not exist]
	at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:492)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:526)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:252)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:238)
	at org.eclipse.jdt.internal.core.Member.getCategories(Member.java:129)
	at org.eclipse.jdt.internal.ui.actions.CategoryFilterActionGroup$CategoryFilter.select(CategoryFilterActionGroup.java:78)
	at org.eclipse.jface.viewers.ViewerFilter.filter(ViewerFilter.java:51)
	at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:900)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:601)
	at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2581)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1867)
	at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:721)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1842)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1799)
	at org.eclipse.jface.viewers.StructuredViewer$8.run(StructuredViewer.java:1514)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1422)
	at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:403)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1383)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1512)
	at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:548)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1469)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaOutlinePage$JavaOutlineViewer.reconcile(JavaOutlinePage.java:371)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaOutlinePage$1.run(JavaOutlinePage.java:161)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3593)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3286)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1384)


 Comments   
Comment by Andrew Eisenberg [ 26/Apr/11 ]

Now fixed. I created a stub getCategories() method in all of the IOJavaElements so that the method need not exist, but an exception is never thrown.





[GRECLIPSE-1042] Unexpected runtime error while computing a text hover Created: 23/Apr/11  Updated: 29/Apr/11  Resolved: 29/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Francois Rey Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Groovy-Eclipse Feature 2.1.3.xx-20110421-2200-e36
eclipse.buildId=M20110210-1200
java.version=1.6.0_25
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.java.product


Attachments: JPEG File hover-screenshot1.jpeg    
Number of attachments : 1

 Description   

Error
Sat Apr 23 19:11:58 CEST 2011
Unexpected runtime error while computing a text hover

java.lang.IllegalArgumentException
at org.eclipse.jdt.core.Signature.getReturnType(Signature.java:1644)
at org.eclipse.jdt.core.Signature.getReturnType(Signature.java:1660)
at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLabelComposer.appendMethodLabel(JavaElementLabelComposer.java:369)
at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLabelComposer.appendElementLabel(JavaElementLabelComposer.java:275)
at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLinks.getElementLabel(JavaElementLinks.java:514)
at org.eclipse.jdt.internal.ui.viewsupport.JavaElementLinks.getElementLabel(JavaElementLinks.java:496)
at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getInfoText(JavadocHover.java:669)
at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo(JavadocHover.java:602)
at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.internalGetHoverInfo(JavadocHover.java:555)
at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo2(JavadocHover.java:547)
at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:141)
at org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo2(JavaEditorTextHoverProxy.java:82)
at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:166)

It happens on a specific instance $

{variable}

inside a gstring.
I can provide the project by personal mail if needed.



 Comments   
Comment by Francois Rey [ 23/Apr/11 ]

On attached screenshot the error always occurs when hovering on $

{infoFile}
Comment by Andrew Eisenberg [ 23/Apr/11 ]

I can't see in the screenshot, but what is the type of the field you are hovering over?

Comment by Francois Rey [ 24/Apr/11 ]

The error occurs in groovy class DrupalGitProject. infoFile is an instance variable declared in the groovy superclass DrupalProject. It's type is DrupalInfoFile, a groovy class in the same package which has nothing much in itself:

class DrupalGitProject extends DrupalProject {
...
abstract class DrupalProject extends EclipseIProject {
public static final java.lang.String STANDALONE = 'standalone'
DrupalComponent drupalComponent
String rootProjectName
DrupalInfoFile infoFile
...
class DrupalInfoFile {
public static final String PHP_INI_OPTION_PATTERN = /\s*(\w+)([\w*])\s=\s*(.*)/
public static final String COMMENT = '; Values below added by Groovy Drupal'
File file = null
...

Comment by Andrew Eisenberg [ 26/Apr/11 ]

I am not able to reproduce this given the information you have currently provided. Can you send me over a copy of the project to my personal email?

It looks to me like the CodeSelect engine (ie- the thing that produces hovers) thinks that infoFile is a method, and so it is failing to produce a correct method signature for the text in the hover.

Comment by Andrew Eisenberg [ 28/Apr/11 ]

Thanks for the test project. I see what is happening now. Groovy-Eclipse is getting confused because there is a field named infoFile and there is also a method named getInfoFile. The inferencing engine wants to choose the getter instead of the actual field. In most cases, this works fine. If you try to navigate (F3), then you are taken to the getter method instead of the field. However, when hovering this breaks since the hover engine is expecting a field, but is passed a method instead.

I'm a little surprised that this hasn't come up earlier since this seems like a fairly typical use case to explicitly override a property with a getter.

I'll experiment a bit more before deciding on the best way to fix.

Comment by Andrew Eisenberg [ 28/Apr/11 ]

Now, the interesting is that when I naively try to recreate this in a simpler project, there is no problem.

Comment by Andrew Eisenberg [ 29/Apr/11 ]

All issues resolved. Committed with regression tests.

Now, code select will try first to match against a method of the exact name, then a field of the exact name. Finally, if neither matches, then getter and setter variants of the name will be tried. This will make the hovers more like what you would expect and there should be no more exceptions when hovering.





[GRECLIPSE-1041] Pasting code into Groovy class will sometimes remove all imports Created: 20/Apr/11  Updated: 06/May/11  Resolved: 06/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Critical
Reporter: Robert La Ferla Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Helios SR2 on OSX


Number of attachments : 0

 Description   

I copied code from one class and when I pasted it in a different class, the plugin removed all my imports. This happens fairly consistently and is a critical issue. I can't continue to use the plugin because this is seriously interfering with my productivity.



 Comments   
Comment by Andrew Eisenberg [ 20/Apr/11 ]

Turn off "organize imports on save" and you should not get this problem any more. This is likely the cause of the problem.

I'd like to fix this, but can't do anything about it unless you tell me how to reproduce. Can you please describe a simple way to reproduce?

Comment by Andrew Eisenberg [ 06/May/11 ]

Closing this issue. Please re-open if you can provide more information.





[GRECLIPSE-1040] StackOverflowError while editing certain .groovy files Created: 19/Apr/11  Updated: 26/Jul/11  Resolved: 26/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Jason Griffith Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MacOS


Attachments: File Bug1040.tgz    
Number of attachments : 1

 Description   

One of our .groovy files will cause StackOverflows if opened in the editor. I don't know what specific property of the file sparks this problem, but the stack trace is pretty clear where the bug is

Caused by: java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getPlainNodeReference(ClassNode.java:1457)
at org.eclipse.jdt.groovy.search.VariableScope.cloneInternal(VariableScope.java:524)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:509)
at org.eclipse.jdt.groovy.search.GenericsMapper.resolveParameter(GenericsMapper.java:83)
at org.eclipse.jdt.groovy.search.GenericsMapper.resolveParameter(GenericsMapper.java:86)
at org.eclipse.jdt.groovy.search.GenericsMapper.resolveParameter(GenericsMapper.java:86)
at org.eclipse.jdt.groovy.search.GenericsMapper.resolveParameter(GenericsMapper.java:86)
...

The 2.1.2 version of the plugin doesn't have any problems.

Please let me know if I can provide any more information.

Thank you!
Jason



 Comments   
Comment by Andrew Eisenberg [ 19/Apr/11 ]

What is the exact version that you are using now? I did some work earlier (post 2.1.2) in this area to avoid a stack overflow, so this may already be fixed. If you can put in your exact Groovy-Eclipse version, I can probably find out if this is has already been fixed.

It is likely a problem with referencing an enum written in groovy inside of a groovy class.

Comment by John Bito [ 19/Apr/11 ]

The version in which we see the problem is Groovy-Eclipse 2.1.3.xx-20110415-0900-e36
There are no enums in our code because Google App Engine causes a SecurityException to be thrown when Groovy 1.7 code uses enums.

Comment by Andrew Eisenberg [ 19/Apr/11 ]

Thanks for that. It looks like this is a different stack overflow. I just committed a change that will prevent a stack overflow by keeping a counter and bottoming out after 10 iterations. This is not a real fix, because I would like to know what is causing the error.

When the recursion bottoms out, an entry is appended to the log with "GRECLIPSE-1040" in the message. This dev build won't be out until tomorrow since I am trying to fix something unrelated. I'll let you know when it is available and can you try it out? After a bit of playing, can you check your error log to see if there are any entries related to this bug report.

Comment by Andrew Eisenberg [ 19/Apr/11 ]

OK. The build has been pushed out. Please try the latest from the dev update site and let me know what you see in your logs.

Comment by Andrew Eisenberg [ 20/Apr/11 ]

Any news on this?

Comment by Jason Griffith [ 20/Apr/11 ]

Crud. Sorry, Andrew, it slipped my mind. I need to wrap up another task or two, and I'll install the latest daily 2.1.3 and get back to you. Might be in a few hours, or tomorrow morning at the latest.

Thanks for checking back!

Comment by John Bito [ 20/Apr/11 ]

Sorry I wasn't able to install the snapshot until just now. With 2.1.3.xx-20110419-1400-e36, I am able to edit the problematic file. The log messages have the body:
RECLIPSE-1040: prevent infinite recursion when resolving type parameters on generics type: E

There is no compile-time class with this name. There is a static map that associates a package-scope class instance to the entry keyed by 'E', but that happens in a static initializer of a class that's used in the problematic file. I can't find anything named 'E' referenced by the file that causes the problem.

If the file is open and I clean, I get a new instance of the message above at the end of the build. If the file is not open (and I have about 20 others open), the message doesn't appear.

Comment by Jason Griffith [ 20/Apr/11 ]

Thanks John!

The problematic file is User.groovy, and it references Currency.groovy. Currency uses the static Map John's referring to in its "public static Currency getAt(entry)" method, so that could look, at run time, like Currency.E is a static property of Currency, and the value of Currency.E is a @PackageScope instance. But run-time properties like that wouldn't be picked up by the "resolving type parameters" operation, would it?

Like John mentioned, nothing in User itself looks "E"-like... Any thoughts on how to drill-down further?

Comment by Andrew Eisenberg [ 21/Apr/11 ]

Thanks, guys for getting back to me. At least you're able to get working again. E is likely the name of an unbound type parameter.

I may have enough information to reproduce now. I'll try a few things and get back to you.

Comment by Andrew Eisenberg [ 21/Apr/11 ]

I haven't been able to reproduce the problem, but I can see where it arises. I'm guessing that there is a recursive generics definition somewhere in your code (typically this is coming from an enum definition, but not always). I added some more code that checks for recursion. I'm still not entirely happy with it, but it is better than the previous workaround I put in.

When this next build comes out, can you give it a spin? If you no longer get the GRECLIPSE-1040 entries in your error log, then this fix is working.

Comment by Jason Griffith [ 03/May/11 ]

Hi Andrew

Sorry about the delay... I installed the latest plugin (2.1.3.xx-20110502-1000-e36) and the log message is still appearing.

"Warning
Tue May 03 11:14:12 PDT 2011
GRECLIPSE-1040: prevent infinite recursion when resolving type parameters on generics type: E"

Comment by Andrew Eisenberg [ 30/May/11 ]

Hi,

Sorry for the long delay. Since we have been able to avoid the problem, it has been less critical to me, but I really would like to fix it.

Is there any chance that you can share your project where you were getting this stackoverflow (and now are getting the log entry)?

Comment by Jason Griffith [ 01/Jun/11 ]

Hi Andrew

I agree on the prioritization

I can't share the project itself, but I'd like to spend some time isolating the problem into an example project I can share. That'll take a little time though, so I may not be able to get to it for a week or two. Would that be ok with you?

Thanks!
Jason

Comment by Andrew Eisenberg [ 01/Jun/11 ]

That's fine with me. The main problem now is a performance issue. Whenever this situation is reached, there is a bit of extra churning going on until we realize that we're going down the same AST node over and over again. Fixing this problem will make things faster for you.

Comment by Andrew Eisenberg [ 25/Jul/11 ]

Any luck on isolating the problem here?

Comment by Andrew Eisenberg [ 26/Jul/11 ]

John, so for you, just this file is generating the exception? I have the project in my workspace now and I am not getting it.

Comment by Andrew Eisenberg [ 26/Jul/11 ]

Spoke too soon. I am getting it. This is great. I should be able to fix the bug now. Thanks for your help.

Comment by Andrew Eisenberg [ 26/Jul/11 ]

Here is the offending code snippet:

new HashSet().addAll(null)

Amazingly simple, isn't it? All my tests involve explicit type parameters or list literals. The problem here is that HashSet with no type parameters is an unresolved type, but the inferencing engine assumes that it should be resolved by the time that the type is received. The problem happens when we need to figure out the resolved type parameter of the addAll method. The inferencing engine is comparing two unresolved {{HashSet}}s and getting into an infinite loop this way.

I have a solution locally. I am going to write up a few tests and commit. Thanks for the test case.

Comment by Andrew Eisenberg [ 26/Jul/11 ]

OK. I have committed the fix with regression tests. Glad that this is figured out. However, if you continue to see the problem even after you have installed the fix, let me know and we can dig deeper.

Comment by Jason Griffith [ 26/Jul/11 ]

Awesome! Thanks Andrew





[GRECLIPSE-1038] NPE in Groovy compiler Created: 18/Apr/11  Updated: 17/Aug/11  Resolved: 17/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, Groovy 1.7 compiler in Greclipse


Number of attachments : 0

 Description   

This code in the Groovy editor

// this is a DSLD file
// start off creating a custom DSL Descriptor for your Groovy DSL

// The following snippet adds the 'newProp' property to all GroovyObjects
currentType('groovy.lang.GroovyObject').accept {
  property name : 'newProp', type : String, provider : 'Sample DSL', doc : 'This is a sample.  You should see this in content assist for GroovyObjects: <pre>newProp</pre>'
}

currentType('java.lang.String').accept {
	method 
		name:'reverberate', 
		type:'Froogle', params:params, useNamedArgs:useNamedArgs, isStatic:isStatic, declaringType:'java.lang.String', provider:'kris', doc:'reverse a String'
}

Causes NPE

eclipse.buildId=unknown
java.version=1.6.0_24
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_CA
Framework arguments:  -product com.springsource.sts.ide
Command-line arguments:  -product com.springsource.sts.ide -data /home/kdvolder/workspaces-sts/tc-dragdrop-runtime -dev file:/home/kdvolder/workspaces-sts/sts-grails/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/dev.properties -os linux -ws gtk -arch x86 -consoleLog


Error
Mon Apr 18 10:43:24 PDT 2011
Groovy bug when compiling.

BUG! exception in phase 'conversion' in source unit '/playDsl/src/kris-dsl.dsld' null
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:957)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:579)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:555)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:532)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.dietParse(GroovyParser.java:429)
	at org.codehaus.jdt.groovy.integration.internal.MultiplexingSourceElementRequestorParser.parseCompilationUnit(MultiplexingSourceElementRequestorParser.java:73)
	at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:194)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:325)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515)
	at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1096)
	at org.codehaus.jdt.groovy.model.GroovyReconcileWorkingCopyOperation.makeConsistent(GroovyReconcileWorkingCopyOperation.java:60)
	at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:410)
	at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1215)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.getModuleNode(GroovyCompilationUnit.java:112)
	at org.codehaus.groovy.eclipse.editor.outline.OCompilationUnit.getNode(OCompilationUnit.java:79)
	at org.codehaus.groovy.eclipse.editor.outline.GroovyScriptOCompilationUnit.refreshChildren(GroovyScriptOutlineExtender.java:76)
	at org.codehaus.groovy.eclipse.editor.outline.OCompilationUnit.refresh(OCompilationUnit.java:86)
	at org.codehaus.groovy.eclipse.editor.outline.GroovyOutlinePage.refresh(GroovyOutlinePage.java:49)
	at org.codehaus.groovy.eclipse.editor.GroovyEditor.synchronizeOutlinePage(GroovyEditor.java:1320)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.synchronizeOutlinePage(JavaEditor.java:2121)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.selectionChanged(JavaEditor.java:2239)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$EditorSelectionChangedListener.selectionChanged(JavaEditor.java:300)
	at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2745)
	at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2693)
	at org.eclipse.jface.text.TextViewer$5.run(TextViewer.java:2672)
	at org.eclipse.swt.widgets.Display.timerProc(Display.java:4106)
	at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
	at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2237)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3159)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
Caused by: java.lang.NullPointerException
	at org.codehaus.groovy.antlr.AntlrParserPlugin.statement(AntlrParserPlugin.java:1305)
	at org.codehaus.groovy.antlr.AntlrParserPlugin.labelledStatement(AntlrParserPlugin.java:1517)
	at org.codehaus.groovy.antlr.AntlrParserPlugin.statement(AntlrParserPlugin.java:1322)
	at org.codehaus.groovy.antlr.AntlrParserPlugin.convertGroovy(AntlrParserPlugin.java:332)
	at org.codehaus.groovy.antlr.AntlrParserPlugin.buildAST(AntlrParserPlugin.java:238)
	at org.codehaus.groovy.control.SourceUnit.convert(SourceUnit.java:298)
	at org.codehaus.groovy.control.CompilationUnit$3.call(CompilationUnit.java:702)
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:948)
	... 54 more




 Comments   
Comment by Andrew Eisenberg [ 17/Aug/11 ]

This code is syntactically incorrect. The newline after 'method' breaks things. All we can do is recover gracefully.

I added a null check and things appear to be behaving. Fix is added for 1.7 and 1.8 streams.





[GRECLIPSE-1037] "Queuing new source whilst already iterating." Created: 14/Apr/11  Updated: 06/Jun/11  Resolved: 06/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.5.1Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The message "Queuing new source whilst already iterating." was added as debug info whilst investigating GRECLIPSE-429, the problem was never solved, but the user who was having it under that bug just stopped seeing it so that bug was closed. A couple of users are now reporting this message appearing again. We need to work out why.



 Comments   
Comment by Andy Clement [ 14/Apr/11 ]

Most recent stack (from Adam Lister):


BUG! exception in phase 'semantic analysis' in source unit '/OBS/src/com/obs/channels/symconnect/client/SymConnectCommand.groovy' Queuing new source whilst already iterating.  Queued source is '/OBS/src/com/obs/channels/symconnect/RequestType.groovy'
   at org.codehaus.groovy.control.CompilationUnit.addSource(CompilationUnit.java:409)
   at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.dietParse(GroovyParser.java:417)
   at org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.dietParse(MultiplexingParser.java:44)
   at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:335)
   at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:140)
   at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
   at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2415)
   at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitScope.lookupClassNodeForSource(GroovyCompilationUnitScope.java:177)
   at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromCompileUnit(JDTResolver.java:167)
   at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:309)
   at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:292)
   at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1345)
   at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:165)
   at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:626)
   at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:694)
   at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:955)
   at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:588)
   at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:537)
   at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:168)
   at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1867)
   at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:816)
   at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:517)
   at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:408)
   at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:322)
   at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:372)
   at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:135)
   at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:268)
   at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:196)
   at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629)
   at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
   at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172)
   at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203)
   at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255)
   at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
   at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258)
   at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311)
   at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343)
   at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
   at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242)
   at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Comment by Andy Clement [ 06/Jun/11 ]

Finally someone kindly shared with me a failing project so I could investigate the cause of this. So thanks to Marcel Wagner!

As predicted as soon as I could recreate it, I could address it. The necessary conditions of this occurring are:

  • you have more than 2000 source files to be compiled together
  • within one 'group' of 2000 source files you have a groovy type that refers to another groovy type that isn't in the same 2000 source files.

Without knowing this, creating a minimal testcase would be tricky.

By configuring the 'chunking' of the compiler (adjusting the 2000) I can recreate a small testcase. I set the chunk size to 10 then I created 9 java files and 2 groovy files, the first groovy file referring to the second. The compiler chose to compile the 9 java files plus one of the groovy files > bang. (due to attempting to fault in the 11th file but not being able to).





[GRECLIPSE-1036] Groovy editors hold jar locks Created: 13/Apr/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Follow on from https://issuetracker.springsource.com/browse/STS-1017 - that addressed locks being held by the compiler, the remaining locks are due to the editor needing to keep things around for usage later.



 Comments   
Comment by Andrew Eisenberg [ 25/Jul/11 ]

Is this still a problem since the GroovySnippetCompiler class moved to using a SearchableEnvironment from a NameEnvironment?

Comment by Andrew Eisenberg [ 08/Sep/11 ]

Assuming this is a duplicate of GRECLIPSE-994





[GRECLIPSE-1035] groovy.swing not exported by org.codehaus.groovy bundle Created: 12/Apr/11  Updated: 21/Apr/11  Resolved: 21/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Francois Rey Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Is there any reason why groovy.swing is not exported by the org.codehaus.groovy bundle?
The following packages are exported, but not groovy.swing:
groovy.swing.binding,
groovy.swing.impl.

This makes groovy.swing.SwingBuilder unaccessible.



 Comments   
Comment by Andrew Eisenberg [ 12/Apr/11 ]

There is no particular reason why we didn't export it other than it is not required by any other Eclipse plugin that we are aware of. I have no problems exporting it.

Can you give a little more background on what you are doing? I'm guessing that this is some kind of plugin development. And also what version of the groovy plugin are you using (1.7 or 1.8)?

Comment by Francois Rey [ 12/Apr/11 ]

Using latest greclipse snapshot, with org.codehaus.groovy 1.7.8. I had to remove 1.8 due to groovy monkey containing groovy-all-1.7.3.jar.
I was trying to remove this jar from groovy monkey and make it use greclipse bundle

Comment by Andrew Eisenberg [ 12/Apr/11 ]

Interesting...does groovy monkey ship with its own org.codehaus.groovy bundle or is the groovy jar contained within one of its other bundles?

I committed the change to the manifests of both of our groovy bundles. Now, they are exporting all of the groovy..* packages as well as all of the org.codehaus.groovy..* packages.

The build may not be available until tomorrow since we have a few failing tests preventing the build from getting published.

Comment by Francois Rey [ 12/Apr/11 ]

Thanks Andrew.
The groovy-all jar is contained within the bundle.
But now I'm having trouble making groovy monkey use org.codehaus.groovy bundle, as if the latter could not see the commons-logging.jar that was also included in groovy monkey. Perhaps I'll try again later if I have more time.

Comment by Andrew Eisenberg [ 12/Apr/11 ]

dev build with the change is now available.

Comment by Francois Rey [ 21/Apr/11 ]

Fix confirmed, I can see the package exported





[GRECLIPSE-1034] renaming with ALT+SHIFT+R doesn't work Created: 07/Apr/11  Updated: 07/Apr/11  Resolved: 07/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Christophe Domas Assignee: Nieraj Singh
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse helios


Attachments: Text File GRECLIPSE_1034_fix_20110407_1607.patch     Microsoft Excel keys.csv    
Number of attachments : 2

 Description   

In key preferences, ALT+SHIFT+R is associated to "Rename variable..." (When Editing GroovySource - Category Groovy Refactoring Command).

But when I type the sequence, it open the Run item of the main menu.



 Comments   
Comment by Andrew Eisenberg [ 07/Apr/11 ]

Hmmm...there could be a keybinding conflict. This keyboard combination is working for me (on mac).

Can you have a look at Preferences -> General -> Keys. Look for an entry "Rename Variable..." when "Editing Groovy Source".

What keybinding is mentioned there and do you see any conflicts?

Just to make sure, I'll check this myself on a windows box as well.

Comment by Christophe Domas [ 07/Apr/11 ]

I have many alt+shift+R binding, but only one in the groovy category.
I join my exported keys as csv, maybe it will help (I saw on the mailing list that somebody had the same problem: http://groovy.329449.n5.nabble.com/Rename-Class-Shortcut-td4266675.html).

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Thanks for the attachment. It looks like this is failing for me on windows as well.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Reassigning to Nieraj, who has found a fix for this.

Comment by Nieraj Singh [ 07/Apr/11 ]

Attached is a fix that enables the short cut key binding for the Groovy rename action. It simply uses the Groovy command ID instead of the JDT ID when adding the action in the GroovyEditor. It has only been tested in Windows, and requires testing in Mac OS and Linux to verify that it does not break the functionality in those platforms.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Thanks for the patch. Testing it on mac right now. As Nieraj discovered, this appears to be a regression from when we rebased on Eclipse 3.6.2.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Hmmm...something's not right for me.

Now, the keybinding defaults to Alt-Shift-R for mac, but it used to default to Alt-CMD-R. Looking a little deeper into this, I found this:

The recognized modifiers keys are M1, M2, M3, M4, ALT, COMMAND, CTRL, and SHIFT. The "M"
modifier keys are a platform-independent way of representing keys, and these are generally preferred.
M1 is the COMMAND key on MacOS X, and the CTRL key on most other platforms. M2 is the SHIFT key.
M3 is the Option key on MacOS X, and the ALT key on most other platforms. M4 is the CTRL key on
MacOS X, and is undefined on other platforms. Since M2+M3+<Letter> (Alt+Shift+<Letter>) is
reserved on MacOS X for writing special characters, such bindings are commonly undefined for
platform="carbon" and redefined as M1+M3+<Letter>.

In the last sentence, it describes that the behavior on Carbon is different from that on Cocoa. Currently, I am on Cocoa, but this is a workspace migrated from Carbon. The odd thing is that in my runtime workspace, the default is the Cocoa bindings, but in my regular workspace, the default is the Carbon bindings. I'm not sure if this is a problem.

So, the patch as it is now seems good, but I just want to explore a bit before committing.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

OK. So, it looks like my ws settings on my workspace is still Carbon (even though it should be Cocoa). That is why my Java Rename shortcuts are CMD-Alt-R, not Shift-Alt-R. JDT UI explicitly changes all keybindings from Shift-Alt-* to CMD-Alt-*. Before this wasn't an issue since we were using the JDT UI command and its binding in the Groovy Editor, but now that we switched to the Groovy command, we use the Groovy key binding.

I made the change in the plugin.xml so that the Shift-Alt-* is explicitly disabled for carbon and use CMD-Alt-* in its place. This is working for me.

I will commit the fix, but I will not close this yet until I hear from a Linux user.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Committed. Will be available in next snapshot build.

Comment by Kris De Volder [ 07/Apr/11 ]

I updated to latest SVN. Then I create a little test program and tried ALT-SHIFT-R to rename some groovy parameters, fields etc. and it seemed to work alright on Linux.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Thanks for checking this out, Kris. Closing now.





[GRECLIPSE-1033] Code completion don't work properly with "Completion overwrites" Created: 07/Apr/11  Updated: 13/Apr/11  Resolved: 12/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Content Assist
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Christophe Domas Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse helios
in java preferences -> Editor -> Content Assist -> completion overwrites


Number of attachments : 0

 Description   

define a variable: def archive = new File(...)
on a new line, type the begining of the variable: arc
ctrl-space and choose the variable "archive" in the lits -> the results will be "archivearc"



 Comments   
Comment by Andrew Eisenberg [ 07/Apr/11 ]

This is not something that we have implemented yet. We should be able to fix this for 2.1.3.

As near as I can tell, this setting is simply ignored when in a Groovy editor.

Comment by Andrew Eisenberg [ 12/Apr/11 ]

The preference constant that controls this setting is:

org.eclipse.jdt.ui.PreferenceConstants.CODEASSIST_INSERT_COMPLETION

value:

content_assist_insert_completion
Comment by Andrew Eisenberg [ 12/Apr/11 ]

I have a solution that is working for field and method completion. It is not yet working for type and constructor completions.

This problem has uncovered a few other inconsistencies with calculating locations for completion. I will fix those as well.

Comment by Andrew Eisenberg [ 12/Apr/11 ]

Complete fix is now committed.

The problem was that the replaceLength was not being computed properly. When completions are in 'insert' mode, the replaceLength is not used, but instead only the replaceStart and actualInsertion point are used. However, when switching to 'overwrite' mode, replaceLength is used. Since we have never tested with this setting enabled, we never encountered the problem.

actualInsertion: the caret location
replaceStart: the starting offset of the insertion token
replaceLength: the total length of the insertion token

Comment by Christophe Domas [ 13/Apr/11 ]

Thanks a lot.





[GRECLIPSE-1030] StackOverflowError in JDTClassNode while editing Created: 01/Apr/11  Updated: 21/Apr/11  Resolved: 21/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Critical
Reporter: Francois Rey Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.6.2 on linux 64bit
Groovy-Eclipse Feature 2.1.3.xx-20110329-1600-e36
Groovy Compiler 1.8 Feature 2.1.3.xx-20110329-1600-e36


Attachments: Text File stackoverflow1.log     Text File stackoverflow2.log     JPEG File stackoverflow-screenshot1.jpeg     JPEG File stackoverflow-screenshot2.jpeg    
Number of attachments : 4

 Description   

A StackOverflowError occurs during groovy code edition and forces quitting eclipse.
This has happened several times while editing code near static initializer.
Unlike GRECLIPSE-1024 there's no generic in the code and eclipse can restart properly.

Here's the error:

!ENTRY org.eclipse.core.jobs 4 2 2011-04-01 15:29:06.567
!MESSAGE An internal error occurred during: "Requesting Java AST from selection".
!STACK 0
java.lang.StackOverflowError
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:203)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:151)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:204)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:151)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:204)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.lazyClassInit(JDTClassNode.java:151)
at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.initialize(JDTClassNode.java:204)

Because this happens frequently I mark this bug as Critical.
See attached log and screenshot.



 Comments   
Comment by Andrew Eisenberg [ 01/Apr/11 ]

This could be another manifestation of the Generics bug associated with enums. Is this the same project you were working on before? Can you send it over again? Or at least tell me where to find the problem (maybe just the single groovy file with the problem is sufficient.

Comment by Andrew Eisenberg [ 01/Apr/11 ]

Looking at the stack frames in your error log, and I would say that this is definitely related to enums. However, so far I have not been able to reproduce this myself.

The two bugs that you have uncovered tell me that we are not testing hard enough for enums that are written in Groovy. This is generally a rare situation, but we should have it covered.

Comment by Francois Rey [ 02/Apr/11 ]

Another occurrence, this time with a longer log (stackoverflow2.log) and a better screenshot (stackoverflow-screenshot2.jpeg) of what I was doing when it occurred:
I basically duplicated 3 lines of code by selecting them, Ctrl+C,down arrow, Ctrl-V, and then StackOverflowError!
The three lines of duplicated code have their number still highlighted in the screenshot (lines 136-138, duplicates of the 3 lines above).

Comment by Andrew Eisenberg [ 02/Apr/11 ]

Yikes. Lots of interesting stack traces in that error log. It might have to wait until Monday until I can have a deep look into the problem.

Comment by Andy Clement [ 03/Apr/11 ]

Francois - I made a slight adjustment to the resolution of JDTClassNodes. Can you grab a snapshot build and see what difference it makes?

http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

Comment by Andy Clement [ 03/Apr/11 ]

actually I'm not happy with that change, so don't feel you have to try it. I'd prefer to recreate before proceeding.

Comment by Andy Clement [ 04/Apr/11 ]

Ok, I've put in a better set of changes. I have recreated the stackoverflow but only when I force it by getting JDTClassNodes to eagerly initialize themselves. I imagine the editor is causing this initialization to be done when the problem happens in the wild, but it doesn't happen for me. Andrew forwarded me the testcode projects and making simple changes in the file at fault, I can't get it to fail. The fixes address the forced failure scenario I can create, hopefully they will help with the real situation too. Should be in a dev build later today.

Comment by Andrew Eisenberg [ 08/Apr/11 ]

Please let us know when you have a chance to try this.

Comment by Francois Rey [ 09/Apr/11 ]

I'm waiting to have a bit more usage before saying it's fine.
I think it is.
When I first had the problem I was spending 30mn on the project here and there and the bug occurred a lot. I'm still juggling with two jobs and I'm not full time on the project where it occurs. I update eclipse everyday and I have to say it's been fine for a few days now.

I also spend some time resolving another problem which probably isn't related: some ClassNotFound on some PowerAssert class or so. In the end I had to remove the groovy 1.8 plugin and run solely on 1.7 to avoid this issue. I think it's because Groovy Monkey includes groovy 1.7 jar.

Bear with me until mid next week and I'll be more confident it's fine.

Thanks for your help.

Comment by Andrew Eisenberg [ 09/Apr/11 ]

I see that PowerAssertionError is in different packages for the versions: org.codehaus.groovy.runtime.powerassert for 1.8, but org.codehaus.groovy.transform.powerassert for 1.7. I'm not sure what kinds of affects this would have for you. It could be a problem if your compiler level is 1.8, but you are referencing 1.7 on your classpath (or vice versa).

Comment by Francois Rey [ 12/Apr/11 ]

I had a full day without seeing this error.
Let's close this issue, I'll reopen it if it ever comes back.
Thanks again.

Comment by Francois Rey [ 21/Apr/11 ]

The fix is working, I have not seen this error in a while.





[GRECLIPSE-1029] Ability to augment/customize the outline view for Groovy scripts and other files Created: 01/Apr/11  Updated: 21/Apr/11  Resolved: 14/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File 0412.org.codehaus.groovy.eclipse.tests     Text File 0412.org.codehaus.groovy.eclipse.ui.patch     Text File GRECLIPSE-1029-final.patch     Zip Archive Jspresso outline.zip     Text File org.codehaus.groovy.eclipse.tests.2.patch     Text File org.codehaus.groovy.eclipse.ui.2.patch    
Issue Links:
dependent
is depended upon by GRECLIPSE-626 [editor] For scripts, add variable de... Resolved
Number of attachments : 6

 Description   

Currently, the outline view for scripts is not too useful. It would be nice to be able to have some custom outline views available for scripts.

Also, in the long term, we should consider exposing an extension point so that third party plugins can provide even more ousomization.



 Comments   
Comment by Andrew Eisenberg [ 01/Apr/11 ]

There is a method JavaEditor.setOutlinePageInput() that could be overridden to supply this information. We would essentially need to pass in a mock IJavaElement that has its children ordered in an appropriate way.

Comment by Maxime HAMM [ 10/Apr/11 ]

Here is my proposition
1. The groovy Outline page manage to fill the outline view and also to synchronize the tree nodes with the editor content. The groovy editor checks all extenders; the first one that returns an outline page will win... by default (of course) the standard outline page is used.
2. The extender receives the IProject and the GroovyCompilationUnit. It should inherit and implement the methods below :
a. OCompilationUnit.refreshChildren : this method will allow the extender to build and refresh the IOJavaElement tree
b. OCompilationUnit.getChildrenAt(int caretOffset) : this method is used to synchronize the Editor view with the outline view
c. OMethod.getElementNameNode, OMethod.getReturnTypeName, OType.getElementNameNode : those methods will determine the outline lines labels
(I have’nt yet implemented a OField classe because I did’nt need it for Jsoresso, but I will do it later)
Maxime

Comment by Maxime HAMM [ 10/Apr/11 ]

The first file is the patch for the org.codehaus.groovy.eclipse.ui project
The second file is the Jspresso DSL extender

Comment by Andrew Eisenberg [ 11/Apr/11 ]

This patch looks good, but there are a few things that need to be worked on before we can apply it.

  • There is no OField class
  • In IOutlineExtender.getGroovyOutlinePageForUnit change method signature to remove the third element. It is redundant since the GroovyCompilationUnit can be retrieved directly from the GroovyEditor.
  • I saw a few e.printStackTrace(). They should be removed. Instead, GroovyCore.logException(...)
  • I don't understand why you overrode getDeclaringType() in OMethod and OType. I think this method can be removed (or tell me why it should remain).
  • In OCompilationUnit, override buildStructure() should be a noop and return true. This method will probably never get called, but if it ever is by accident, it could cause some big problems with the mode.
  • Delete: OCompilationUnit.getGroovyNode(). Seems like this method shouldn't be there.
  • Here is a big one...OutlineExtenderRegistry should not base which extender to use only on the nature. This can be problematic because let's say someone produces an extender for vanilla groovy projects so that scripts can have a custom outline view. We can safely assume that there will only be one extender per compilation unit, but I don't think we can assume there will be one per file.

Here is a suggestion:

1. add new method to IOutlineExtender:

boolean appliesTo(GroovyCompilationUnit);

Returns true if should be used for a particular file or false if not applicable.

2. this will allow someone to create a script outline enhancer (which I am planning to do) that applies to all projects with a groovy nature

3. Now, it might be that we want to lower the priority of the groovy script extender so that (for example) the jspresso plugin would have its extender run instead of the default groovy one. You may need to then force the ordering of the OutlineExtenderRegistry.natureToExtenderMap field so that extenders associated with groovy projects appear last.

  • Why does OMethod have a getElementNameNode()? That feels very specific to your own implementation. Can you document why this is general purpose and how to use it, or else remove it? I see that the method is used in OMethodInfo.getNameSourceStart() and OMethodInfo.getNameSourceEnd(). Instead of getElementNameNode(), why not have getNameStart() and getNameEnd()?
  • Last, of course, is discussing the testing, which I'll do in another comment.
Comment by Andrew Eisenberg [ 11/Apr/11 ]

From the mailing list:

About tests :
1) test the extension point stuff:

  • if there is no extenders then the outline contains the classical methods (main, etc.)
  • if there is one extenders that should create an outline O1 then the created outline is an O1 instance.
  • if there is two declared extenders, the first one wins.
    2) test the outline content.
    Let's say we have a test extender that produces an outline that contains a tree of OTypes that should be synchronized with groovy methods and inline methods. Each node contains also OMethod and OField sub nodes linked to the groovy...
  • test the outline content consistency
  • change one method : test outline content consistency
  • change one line method : test outline content consistency
  • remove one method : test outline content consistency
  • remove one inline method : test outline content consistency
  • add one method : test outline content consistency
  • add one inline method : test outline content consistency
  • select one IOElement : test selected groovy method consistency
  • select one groovy method : test selected IOElement node

Regards,
Maxime

This seems to me to be a fairly complete list of tests. One comment, though...your test:

  • if there is two declared extenders, the first one wins.

The behavior will be undefined if two or more extenders apply to the same file. I think this is OK. But, you will also have to add a test for boolean IOutlineExtender.appliesTo(GroovyCompilationUnit).

Now, here are some suggestions and APIs that you can use to create the tests:

  • check out all of the plugins in https://svn.codehaus.org/groovy/eclipse/trunk/ide-test/ and from https://svn.codehaus.org/groovy/eclipse/trunk/test/
  • You can add your tests to the org.codehaus.groovy.eclipse.tests plugin
  • Your test class can subclass org.codehaus.groovy.eclipse.test.EclipseTestCase.
  • The test plugin already defines two test natures that you can use in your tests. You can create a couple of test extensions for the outline extender in the plugin.
  • The EclipseTestCase class has a field of type TestProject. You can use this field to perform many operations on java projects like add/remove natures, add/remove java and groovy classes, etc. This should be sufficient for what you need to do.
  • We don't do SWT testing, so there is no need to test that clicking on an outline selection will take you to the correct part of the code. This is manual testing that we do just prior to releases.

Let me know if you have any questions.

Comment by Maxime HAMM [ 12/Apr/11 ]

Hi Andrew

Here is a new proposal. I think I succeed to take account the changes you asked me. I also added some Javadoc.

I attach a first draft code for tests... I think the first tests are fine... but tests about outline content aren't reliable : i would have base my tests onto Tree/TreeItems but i didn't find any solution...then I base my test on OType/OMethod/OFields... What do you think about that ?

Regards,
Maxime

Comment by Andrew Eisenberg [ 12/Apr/11 ]

This looks great. The test coverage is fine as it is. It is not easy to do tests based on JFace components so, we usually test the model that the JFace components are based on. This has worked fine for us in the past.

I see what you mean that the tests are unreliable. There is one test that is failing when run with the other tests, but it passes when it runs alone. I'm not exactly sure what the problem is, but it is probably something to do with the working copy or the indexes not being completely initialized.

I'll have a look at it tomorrow.

Comment by Andrew Eisenberg [ 13/Apr/11 ]

OK. I fixed the tests. They are now passing reliably for me. I had to make a few changes to the tests as well as one or two changes to the plugin code.

The biggest change that I made was to ensure that the groovy compilation unit was already a working copy and already reconciled before creating the outline view. This would ensure that GroocyCompilationUnit.getModuleNode() never returns null.

This makes the tests pass, but it does make me a little concerned that we will get into situations when opening and editor and the outline view will be empty because the outline page was initialized too early (and could not get a ModuleNode). I don't know if this will be a problem, but we will see.

Comment by Andrew Eisenberg [ 13/Apr/11 ]

Resolving this issue now and committing the code. Thanks for your contribution!

Comment by Andrew Eisenberg [ 13/Apr/11 ]

On second thought. Not quite ready to commit this.

The major problem now is the expectation that once you are using an extended Outline page now, then all contained JavaElements will be OJavaElements. This doesn't really work since, for example in a script, you may have a standard method declaration or standard class declarations. These need to appear in the outline view as well, and I don't think we should be using wrappers for them.

Comment by Maxime HAMM [ 13/Apr/11 ]

Hello Andrew

OK, the groovy outline view should also be able to receive normal IJavaElement or may be a mix of IJavaElement and IOJavaElement...

Here is a new proposition (incremental patches to apply after previous ones),

Thanks a lot... i'am happy to contribute to groovy eclipse code :o)

Comment by Andrew Eisenberg [ 13/Apr/11 ]

Thanks for the updated patch, but I have already made a bunch of local changes. Now, it is going to be very hard to apply your new changes. Times like this, I wish we were using git. Don't worry about this. I'll incorporate your changes.

Comment by Maxime HAMM [ 14/Apr/11 ]

Just for me to know... will you finalize this soon ?

Comment by Andrew Eisenberg [ 14/Apr/11 ]

Yes. I hope to do so today or tomorrow.

Comment by Andrew Eisenberg [ 14/Apr/11 ]

Here is the final patch that I will be committing. Take a look at it. The major changes are these:

  • Use getSourceElementAt() instead of getSourceReferenceAt(). This makes the OJavaElements more aligned with IJavaElements
  • Override buildStructure as a no-op in OCompilationUnit to make sure the method never gets called and causes some really bad things to happen
  • Created the GroovyScriptOutlineExtender for all groovy scripts
  • The OutlineExtenderRegistry will try the GroovyScriptOutlineExtender if no other outline extenders are used. It is not registered as a regular extension point
  • Allow multiple extenders to be registered per nature
  • Add some more tests for the groovy script extender.

Thanks for the initial work on this. I don't think this would ever had been implemented without your patch.

Comment by Andrew Eisenberg [ 14/Apr/11 ]

Work is committed. Will be available in next dev build. Two things I notice:

  1. When using an extender, most of the outline buttons are disabled. They are explicitly removed from within GroovyOutlinePage.initializeViewer(). Was there a reason for this? (I never use them and I don't even know if they work in Groovy).
  2. If you start off with your Groovy file as a regular file, but then turn it into a script, the outline view does not change to reflect that. You must close and re-open the editor before the extended outline view is used. This is not really a big problem, I think.
Comment by Andrew Eisenberg [ 14/Apr/11 ]

Initial work is complete. May open new issues for the bullet points in the previous comments.

Comment by Maxime HAMM [ 15/Apr/11 ]

Thank you Andrew !

About the "getSourceReferenceAt" : this method is used to select a part of code in the editor when some node is selected... the outline page expected a "ISourceReference" that can be à JavaElement but may be something else ? That's not important, i see that you kept the return type as ISourceReference...

About the button, yes i think they are currently not working... I was thinking someone will work on that later and add some specific Groovy buttons... may be i will do it for my Jspresso plugin.

It works fine in debug mode... i'm waiting the groovy eclipse site update to finalize my tests...

Comment by Andrew Eisenberg [ 15/Apr/11 ]

Dev build is now available. Let me know if it works for you.

Comment by Maxime HAMM [ 18/Apr/11 ]

Hello Andrew !
It works fine,
It is a new great feature for Jspresso DSL !
Thank you for your help
Maxime

Comment by Maxime HAMM [ 18/Apr/11 ]

Here is the Jspresso implementation for the outline feature
Hope this will help some other Groovy Eclipse developpers
Maxime
www.jspresso.org





[GRECLIPSE-1028] Classes that are imported by default are not resolved in the editor anymore Created: 01/Apr/11  Updated: 02/Apr/11  Resolved: 02/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Minor
Reporter: Rene Scheibe Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive DefaultImportMissing.tar.gz    
Number of attachments : 1

 Description   

When using a Groovy class from a Java class, it looks like the default imports (e.g. java.util.Map) are not resolved. The code compiles and runs fine. But in the Editor view the following errors are visible:

  • The method execute() from the type GroovyClass refers to the missing type Map
  • Eclipse: Map cannot be resolved to a type
  • Eclipse: The return type is incompatible with GroovyClass.execute()

When the classes that should be imported by default in Groovy, are imported explicitely (as in Java) the errors are gone.

I have attached an example project showing this.



 Comments   
Comment by Andrew Eisenberg [ 01/Apr/11 ]

What version are you using? Latest release (2.1.2) or the dev snapshot?

Comment by Andrew Eisenberg [ 01/Apr/11 ]

I imported your project into a workspace that uses the latest dev build and could not reproduce any of your problems. It seems like you are describing reconciling errors (ie- errors that come from behind the scenes error checking as you type).

Since I can't reproduce, it's hard to say what's going on. Here are some things to try/make sure:

  1. Are you using Groovy 1.7 or 1.8?
  2. Make sure that your Java files are opening in Java editors and your Groovy files are in Groovy Editors
  3. Make sure that "Build Automatically" is checked (also perform a Clean... build for good measure).
  4. Make sure that the "Groovy Libraries" classpath container is valid and contains a proper Groovy-all library.
  5. Take a peek at your error log and see if there are any relevant errors.
  6. Try deleting your project from the workspace (but not the file system) and then re-importing it
  7. And if all else fails, try uninstalling and reinstalling the Groovy-Eclipse plugin.

Please let me know if any of this works for you.

Comment by Rene Scheibe [ 01/Apr/11 ]

I selected 2.1.3 when creating the ticket - exactly it's:

Version: 2.1.3.xx-20110317-1200-e36
Compiler: 1.7.8.xx-20110317-1200-e36

Now I upgraded to the new version the below version bu the errors are still visible:
Version: 2.1.3.xx-20110329-1600-e36)

Looks like a former upgrade went wrong (I already had the same problem some months ago) and 2 versions of the plugin are installed at the same time. Setting up Eclipse from scratch resolved the errors.

Do you have any idea how this 2 version thing can happen? Setting up Eclipse from scratch every time this happens is frustrating.

Comment by Rene Scheibe [ 01/Apr/11 ]

These have been the files when the 2 versions conflicted:

eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110121-1600-e36
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110121-1600-e36/conf/groovy-starter.conf
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110121-1600-e36/lib/groovy-1.6.7.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110121-1600-e36/lib/groovy-all-1.6.7-sources.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110121-1600-e36/lib/groovy-all-1.6.7.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110121-1600-e36/lib/groovy-1.6.7-sources.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110121-1600-e36/groovy-eclipse.jar
eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.completion_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.refactoring_2.1.2.xx-20110121-1600-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.codebrowsing.source_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.completion_2.1.2.xx-20110121-1600-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse_2.1.2.xx-20110121-1600-e36
eclipse/plugins/org.codehaus.groovy.eclipse_2.1.2.xx-20110121-1600-e36/groovy32.png
eclipse/plugins/org.codehaus.groovy.eclipse_2.1.3.xx-20110317-1200-e36
eclipse/plugins/org.codehaus.groovy.eclipse_2.1.3.xx-20110317-1200-e36/groovy32.png
eclipse/plugins/org.eclipse.jdt.groovy.core.tests.compiler_3.3.100.xx-20110121-1600-e36
eclipse/plugins/org.eclipse.jdt.groovy.core.tests.compiler_3.3.100.xx-20110121-1600-e36/groovy-170.jar
eclipse/plugins/org.eclipse.jdt.groovy.core.tests.compiler_3.3.100.xx-20110121-1600-e36/astTransformations/LoggingExample.groovy
eclipse/plugins/org.eclipse.jdt.groovy.core.tests.compiler_3.3.100.xx-20110121-1600-e36/astTransformations/LoggingASTTransformation.groovy
eclipse/plugins/org.codehaus.groovy.eclipse.ant_2.1.3.xx-20110317-1200-e36
eclipse/plugins/org.codehaus.groovy.eclipse.ant_2.1.3.xx-20110317-1200-e36/org/codehaus/groovy
eclipse/plugins/org.codehaus.groovy.eclipse.ant_2.1.3.xx-20110317-1200-e36/groovyAntEclipse.jar
eclipse/plugins/org.codehaus.groovy.eclipse.ui_2.1.2.xx-20110121-1600-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.astviews_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.eclipse.jdt.groovy.core_2.1.2.xx-20110121-1600-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.codebrowsing_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.astviews.source_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.codebrowsing_2.1.2.xx-20110121-1600-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.quickfix_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110317-1200-e36
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110317-1200-e36/conf/groovy-starter.conf
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110317-1200-e36/lib/groovy-1.6.7.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110317-1200-e36/lib/groovy-all-1.6.7-sources.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110317-1200-e36/lib/groovy-all-1.6.7.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110317-1200-e36/lib/groovy-1.6.7-sources.jar
eclipse/plugins/org.codehaus.groovy_1.6.7.xx-20110317-1200-e36/groovy-eclipse.jar
eclipse/plugins/org.codehaus.groovy_1.7.5.xx-20110121-1600-e36
eclipse/plugins/org.codehaus.groovy_1.7.5.xx-20110121-1600-e36/conf/groovy-starter.conf
eclipse/plugins/org.codehaus.groovy_1.7.5.xx-20110121-1600-e36/lib/groovy-1.7.5-sources.jar
eclipse/plugins/org.codehaus.groovy_1.7.5.xx-20110121-1600-e36/lib/groovyReset.jar
eclipse/plugins/org.codehaus.groovy_1.7.5.xx-20110121-1600-e36/lib/groovy-all-1.7.5.jar
eclipse/plugins/org.codehaus.groovy_1.7.5.xx-20110121-1600-e36/lib/groovy-1.7.5.jar
eclipse/plugins/org.codehaus.groovy_1.7.5.xx-20110121-1600-e36/lib/groovy-all-1.7.5-sources.jar
eclipse/plugins/org.codehaus.groovy_1.7.5.xx-20110121-1600-e36/groovy-eclipse.jar
eclipse/plugins/org.codehaus.groovy.eclipse.core.source_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.ant_2.1.2.xx-20110121-1600-e36
eclipse/plugins/org.codehaus.groovy.eclipse.ant_2.1.2.xx-20110121-1600-e36/org/codehaus/groovy
eclipse/plugins/org.codehaus.groovy.eclipse.ant_2.1.2.xx-20110121-1600-e36/groovyAntEclipse.jar
eclipse/plugins/org.codehaus.groovy.eclipse.ui_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.astviews_2.1.2.xx-20110121-1600-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.completion.source_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.refactoring.source_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.core_2.1.2.xx-20110121-1600-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.quickfix.source_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.source_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.ui.source_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.quickfix_2.1.2.xx-20110121-1600-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.core_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.eclipse.jdt.groovy.core_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy.eclipse.refactoring_2.1.3.xx-20110317-1200-e36.jar
eclipse/plugins/org.codehaus.groovy_1.7.8.xx-20110317-1200-e36
eclipse/plugins/org.codehaus.groovy_1.7.8.xx-20110317-1200-e36/conf/groovy-starter.conf
eclipse/plugins/org.codehaus.groovy_1.7.8.xx-20110317-1200-e36/lib/groovy-1.7.8.jar
eclipse/plugins/org.codehaus.groovy_1.7.8.xx-20110317-1200-e36/lib/groovyReset.jar
eclipse/plugins/org.codehaus.groovy_1.7.8.xx-20110317-1200-e36/lib/groovy-all-1.7.8-sources.jar
eclipse/plugins/org.codehaus.groovy_1.7.8.xx-20110317-1200-e36/lib/groovy-all-1.7.8.jar
eclipse/plugins/org.codehaus.groovy_1.7.8.xx-20110317-1200-e36/lib/groovy-1.7.8-sources.jar
eclipse/plugins/org.codehaus.groovy_1.7.8.xx-20110317-1200-e36/groovy-eclipse.jar

Comment by Andrew Eisenberg [ 01/Apr/11 ]

What makes you certain that there was a version conflict? (I'm not trying to be coy or rude here...I'm genuinely asking.)

Just because there are multiple versions in your directory, it doesn't mean that both versions are installed. Eclipse will sometimes leave old versions around even if they have been superseded by new versions. I'm not exactly sure why it does this. It could have something to do with the same Eclipse installation being used for multiple workspaces, or it could just be some kind of optimization that p2 uses so users can revert to older versions.

To check what versions are actually installed, go to "About Eclipse" -> Installation details -> Installed plugins.

But, there could be some other problem going on and that would be revealed in the error log. It is odd that you've had this happen twice to you, but I can't reproduce.

Comment by Rene Scheibe [ 02/Apr/11 ]

I did not know that multiple versions of a plugin can be present in the Eclipse plugin folder. So this was what I called the version conflict.

As it's not reproducable by you and a fresh installation is also fine, I will close the ticket.

Comment by Andrew Eisenberg [ 02/Apr/11 ]

Thanks for getting back to me. Please let me know if you experience this again and we can look a little deeper.





[GRECLIPSE-1027] When hovering over inferred members, the hover target is incorrect Created: 29/Mar/11  Updated: 01/Apr/11  Resolved: 01/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When hovering over a method or property that has been added through inferencing, the hover target is the declaring type of that property or method. This is confusing to users. The problem is that the hover engine requires a JavaElement that exists, and so we can't simply pass in the inferred property/method since it doesn't exist.

Instead, we need to co-opt the hovers and insert some information ourselves.



 Comments   
Comment by Andrew Eisenberg [ 01/Apr/11 ]

I think I have a good fix for this. Now, when creating the hover, I detect if the correct name is different from the name of the actual name of the selected IJavaElement. If so, then the hover adds the correct name at the very top of the hover box.





[GRECLIPSE-1026] Groovy:The class java.util.List refers to the class java.util.List and uses 1 parameters, but the referred class takes no parameters Created: 26/Mar/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Minor
Reporter: George Richmond Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 32 bit.
Affects STS 2.6.0, but this is not listed as an option above.


Number of attachments : 0

 Description   

Use of generic, such as

List<Location> broaderItems

produces IDE error: Groovy:The class java.util.List refers to the class java.util.List and uses 1 parameters, but the referred class takes no parameters.

Removing the generic and just having a plain List removes the error.



 Comments   
Comment by Kevin Dean [ 19/Apr/11 ]

Also received this error message when configuring an existing project in STS 2.6.0. Found that Compiler compliance level, source compatibility etc. had defaulted to 1.4. Fixed once these were changed to 1.6.

Comment by Andrew Eisenberg [ 25/Jul/11 ]

I'm resolving this issue since it appears to be related to compliance levels. Please re-open if the problem is indeed something different.





[GRECLIPSE-1024] StackOverflowError in VariableScope while editing, eclipse cannot start anymore Created: 24/Mar/11  Updated: 25/Mar/11  Resolved: 25/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Blocker
Reporter: Francois Rey Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.6.2 linux 64bit


Attachments: Zip Archive .bak_0.log.zip     Text File greclipse-bug-console1.txt     JPEG File greclipse-bug-screenshot1.jpeg     JPEG File greclipse-bug-screenshot2.jpeg    
Number of attachments : 4

 Description   

While editing some groovy class, I got s tack overflow error. Had no choice but to restart the workspace unfortunately eclipse does not start anymore. Pasted below is the relevant .log section:

Note that the 'Widget disposed too early' errors only occurred after restarting eclipse. The stack overflow error happened originally without such errors. In any case there are other errors that occurred in the hours/days preceding this that you can see in attached log.

!ENTRY org.eclipse.ui.workbench 4 0 2011-03-24 09:05:07.158
Unable to render embedded object: File (MESSAGE Widget disposed too early) not found.
!STACK 0
java.lang.RuntimeException: Widget disposed too early!
at org.eclipse.ui.internal.WorkbenchPartReference$1.widgetDisposed(WorkbenchPartReference.java:172)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1263)
at org.eclipse.swt.widgets.Widget.release(Widget.java:1080)
at org.eclipse.swt.widgets.Control.release(Control.java:3304)
at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1293)
at org.eclipse.swt.widgets.Widget.release(Widget.java:1083)
at org.eclipse.swt.widgets.Control.release(Control.java:3304)
at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1293)
at org.eclipse.swt.widgets.Widget.release(Widget.java:1083)
at org.eclipse.swt.widgets.Control.release(Control.java:3304)
at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1293)
at org.eclipse.swt.widgets.Widget.release(Widget.java:1083)
at org.eclipse.swt.widgets.Control.release(Control.java:3304)
at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1293)
at org.eclipse.swt.widgets.Canvas.releaseChildren(Canvas.java:208)
at org.eclipse.swt.widgets.Decorations.releaseChildren(Decorations.java:469)
at org.eclipse.swt.widgets.Shell.releaseChildren(Shell.java:2305)
at org.eclipse.swt.widgets.Widget.release(Widget.java:1083)
at org.eclipse.swt.widgets.Control.release(Control.java:3304)
at org.eclipse.swt.widgets.Widget.dispose(Widget.java:462)
at org.eclipse.swt.widgets.Shell.dispose(Shell.java:2241)
at org.eclipse.swt.widgets.Display.release(Display.java:3211)
at org.eclipse.swt.graphics.Device.dispose(Device.java:246)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:131)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
at org.eclipse.equinox.launcher.Main.main(Main.java:1384)

!ENTRY org.eclipse.osgi 4 0 2011-03-24 09:05:07.272
!MESSAGE Application error
!STACK 1
java.lang.StackOverflowError
at org.codehaus.jdt.groovy.internal.compiler.ast.LazyGenericsType.ensureInitialized(LazyGenericsType.java:130)
at org.codehaus.jdt.groovy.internal.compiler.ast.LazyGenericsType.getType(LazyGenericsType.java:47)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:487)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:472)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:493)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:472)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:493)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:472)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:493)
(etc.)



 Comments   
Comment by Francois Rey [ 24/Mar/11 ]

When starting eclipse with the -clean option the eclipse window appears with the editors (did not even appear before). However the stack overflow happens just after again. Because I ran eclipse from the console I saw what appears to be some groovy compiler errors complaining it cannot find a class. Why would these errors be printed on stdout? See console output further below.
In any case adding the proper import removed the stack overflow error!
So I'm back in business but this bug is a real show stopper. Gladly the console output gave some pointers for resolving the problem.

>eclipse.sh -clean
org.codehaus.groovy.control.messages.SyntaxErrorMessage@4cedd1e2
org.codehaus.groovy.control.messages.SyntaxErrorMessage@14981e0
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 17 Groovy:unable to resolve class EclipseIProject
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 17 Groovy:unable to resolve class EclipseIProject
org.codehaus.groovy.control.messages.SyntaxErrorMessage@25a296b8
org.codehaus.groovy.control.messages.SyntaxErrorMessage@46f8e337
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 17 Groovy:unable to resolve class EclipseIProject
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 17 Groovy:unable to resolve class EclipseIProject
org.codehaus.groovy.control.messages.SyntaxErrorMessage@10f48f0c
org.codehaus.groovy.control.messages.SyntaxErrorMessage@34e654db
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 17 Groovy:unable to resolve class EclipseIProject
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 17 Groovy:unable to resolve class EclipseIProject
org.codehaus.groovy.control.messages.SyntaxErrorMessage@4a8f5018
org.codehaus.groovy.control.messages.SyntaxErrorMessage@26ee8a8a
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 17 Groovy:unable to resolve class EclipseIProject
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 17 Groovy:unable to resolve class EclipseIProject

Comment by Francois Rey [ 24/Mar/11 ]

Here's another instance of this stack overflow, stacktrace is slightly different but it's the same infinite loop, see also attached screenshot (greclipse-bug-screenshot1.jpeg) showing the error popup and the location where I was editing code when it occured. I also attach the console output until it occured (greclipse-bug-console1.txt)

!SESSION 2011-03-24 10:05:54.681 -----------------------------------------------
eclipse.buildId=M20110210-1200
java.version=1.6.0_24
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.java.product -clean

This is a continuation of log file /home/francois/workspace-3.6/.metadata/.bak_2.log
Created Time: 2011-03-24 11:38:37.361

!ENTRY org.eclipse.ui 4 4 2011-03-24 11:38:37.361
!MESSAGE Save All Failed

!ENTRY org.eclipse.ui 2 0 2011-03-24 11:38:37.361
!MESSAGE Save All Failed
!STACK 0
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:1011)
at org.codehaus.groovy.ast.ClassNode.getPlainNodeReference(ClassNode.java:1431)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:457)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:487)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:472)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:487)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:472)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:493)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:472)
at org.eclipse.jdt.groovy.search.VariableScope.clone(VariableScope.java:493)
(etc.)

Comment by Francois Rey [ 24/Mar/11 ]

Shows the error popup when it occured, I also highlighted the position where I was editing code when it occured

Comment by Francois Rey [ 24/Mar/11 ]

Console output of eclipse until I was forced to kill the eclipse process. Correspond to previous screenshot (greclipse-bug-screenshot1.jpeg) and second comment made. The last message on this output does not correspond to the time the error occurred but to a few edits earlier in the same file. I don't think this output is directly related to the stack overflow. It does however show a lot of messages from greclipse, some being errors with stacktraces.

Comment by Andrew Eisenberg [ 24/Mar/11 ]

It looks like most of the stack traces in the console are coming from syntax errors in your code:

/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 10 Groovy:Cannot use return statement with an expression on a method that returns void
exception handling
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during class generation: Cannot use return statement with an expression on a method that returns void
. At [10:46] /Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy

Does this compile problem make sense to you? Or do you think this is valid code?

The infinite loop, however, is definitely worrisome. I'm not sure of several things:

  1. Why wasn't the error reported in your Problems view? Perhaps there was a compiler crash before it could get there, but I didn't see anything.
  2. The infinite loop is being caused when trying to resolve generic type information for the type of an expression. It looks like for some reason the compiler created an invalid hierarchy of type parameter resolution where something like type parameter A resolved to itself. Again, I don't know what could have caused this, but it must have been related to the compiler crash before.

I'll have a deeper look.

Just to make aure...you are no longer experiencing the stack overflow, but you (rightfully) want to make sure it doesn't happen again? If you are currently experiencing problems, I can put a stop-gap measure in to get you working now while I figure out a more complete solution.

Comment by Francois Rey [ 24/Mar/11 ]

Thanks for looking into this.
I had the error a few times more since my last comment, and each time I had to restart -clean after making some changes to the file that was edited beforehand.
The code is fine, I can run it ok. This error happens while editing code.
Maybe it's related to my constant refactoring. I took the habit of coding several classes in one file before splitting them into separate files. But sometimes the refactoring "move to a new file" cannot proceed and displays an error.
I also cleaned the project to make sure all is fine.
The stopgap measure would be great because present workaround is definitely time-consuming.

Comment by Andrew Eisenberg [ 24/Mar/11 ]

OK. Done. I committed a change such that there is a depth counter in the VariableScope.clone() method. Now, the method will not be called more than 10 times recursively before bottoming out and stopping.

I'd obviously prefer to get to the root of this problem, but this should help you get started.

The build should be available in about an hour from the snapshot update site:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

Comment by Andrew Eisenberg [ 24/Mar/11 ]

In the meantime, some more questions:

  • What version of Groovy are you using? 1.7.x or 1.8.x?
  • Can you send over a copy of the project that is causing you problems? I understand that this is likely proprietary and you won't be able to do it, but if you can that would greatly simplify things. You could send it to me directly via email and I will keep it private. (aeisenberg at vmware dot com)
  • If you can't send over the entire project, can you send me the problematic file(s)? Try to include any related files that using generic type parameters.
  • Can you be more specific about when the refactoring problem happens for you? We have tests to make sure it works in simple scenarios, but I am sure there are more complicated situations where it is not working.
Comment by Francois Rey [ 24/Mar/11 ]

The error just occurred again, see attached screenshot (greclipse-bug-screenshot2.jpeg)

Here's the relevant console output

org.codehaus.groovy.control.messages.SyntaxErrorMessage@5eb39178
org.codehaus.groovy.control.messages.SyntaxErrorMessage@5f138dda
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 97 Groovy:unexpected token: } @ line 97, column 1.
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 67 Groovy:expecting '}', found 'property' @ line 67, column 86.
Abort compilation
org.codehaus.groovy.control.messages.SyntaxErrorMessage@70721132
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 65 Groovy:illegal string body character after dollar sign;
org.codehaus.groovy.control.messages.SyntaxErrorMessage@15b5e549
org.codehaus.groovy.control.messages.SyntaxErrorMessage@58e026c1
org.codehaus.groovy.control.messages.SyntaxErrorMessage@6410767c
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 66 Groovy:expecting EOF, found 'return' @ line 66, column 4.
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 65 Groovy:unexpected token: . @ line 65, column 33.
/Drupal Groovy/src/org/soft4hearts/drupal/model/DrupalWebsiteProjects.groovy: 66 Groovy:unexpected token: return @ line 66, column 4.

Comment by Francois Rey [ 24/Mar/11 ]

Here are a few plugin versions taken from my eclipse plugins directory:
org.codehaus.groovy.eclipse_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.astviews_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.astviews.source_2.1.3.xx-20110322-1600-e36.jar
org.codehaus.groovy.eclipse.codeassist.completion_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.codeassist.completion.source_2.1.3.xx-20110322-1600-e36.jar
org.codehaus.groovy.eclipse.codebrowsing_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.codebrowsing.source_2.1.3.xx-20110322-1600-e36.jar
org.codehaus.groovy.eclipse.core_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.core.source_2.1.3.xx-20110322-1600-e36.jar
org.codehaus.groovy.eclipse.quickfix_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.quickfix.source_2.1.3.xx-20110322-1600-e36.jar
org.codehaus.groovy.eclipse.refactoring_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.refactoring.source_2.1.3.xx-20110322-1600-e36.jar
org.codehaus.groovy.eclipse.source_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.ui_2.1.2.xx-20110310-1500-e36.jar
org.codehaus.groovy.eclipse.ui.source_2.1.3.xx-20110322-1600-e36.jar
org.codehaus.gradle_0.9.2.201102071452:
org.codehaus.groovy_1.6.7.xx-20110310-1500-e36:
org.codehaus.groovy_1.7.8.xx-20110310-1500-e36:

I'm also using groovyMonkey 0.6.1 (actually a version I slightly modified, see https://github.com/fmjrey/Groovy-Monkey)

Comment by Andrew Eisenberg [ 24/Mar/11 ]

I was hoping to get the workaround out to you sooner, but our bamboo server has crashed and no builds are being run. I'll let you know when the new build is available.

Comment by Andrew Eisenberg [ 24/Mar/11 ]

Some more questions:

  1. Are you running any custom AST transforms that might have some affect on type hierarchies or generics?
  2. May any of your Groovy Monkey scripts make any changes to the Groovy ASTs in the editor?
Comment by Andrew Eisenberg [ 24/Mar/11 ]

I am fairly certain that your problem has something to do with this declaration in your code:

Map<DrupalComponentType, Map<String, ? extends IEclipseProject>> contributionByTypes

Generics in Groovy are not used very often and not very well tested in the Groovy compiler or in Groovy-Eclipse. Over the last few days, however, I have been working a bit in this area. Even though the workaround I described above is not yet available, you may want to try the latest snapshot build (from yesterday). This contains some fixes for handling generics. I don't know of anything specific that would affect what you are working on, but this may help something.

Comment by Francois Rey [ 24/Mar/11 ]

In my code I'm not doing any AST thing.
I don't think Groovy Monkey is even involved here since I'm using the Groovy Eclipse editor.
Also the bug happens when editing, not when running the script.
Generics may be the issue, since the error tends to appear on the same file containing generics while editing a GString.
I'll try the snapshot build (was using it but then reverted to milestone after having many errors).
I also sent you the culprit project by personal mail.

Comment by Andrew Eisenberg [ 24/Mar/11 ]

Thanks for sending me the project. I was able to reproduce your problem and the fix I put in avoids the stack overflow. The build is now available from the dev update site about.

This is not a permanent fix since there is still quite a bit of extra work being done when it shouldn't, but it will get you going again.

The problem was with how we handled field references inside enums that are defined in Groovy. Since enums have a recursive type parameter (ie enum Enum<E extends Enum> we were not handling this recursive definition properly.

This problem has been in Groovy-Eclipse for a long time and so I am surprised no one else has come across it. When I have a better solution and a few tests written for it, I'll close this bug.

Comment by Andrew Eisenberg [ 25/Mar/11 ]

OK. I have a reasonable solution now. When resolving type parameters in the editor and we come across a type parameter that references itself, we simply convert the self-reference to an Object reference. This does not seem to affect resolution behavior for type inferencing.

Fix is not yet committed, but I will once tests are ready.

One thing I do notice is that we are not handling upper bounds very well.

Comment by Andrew Eisenberg [ 25/Mar/11 ]

Fixed now with regression tests. I will open a new bug for the upper bounds problem.

Comment by Andrew Eisenberg [ 25/Mar/11 ]

See GRECLIPSE-1025.





[GRECLIPSE-1023] Inline rename refactor of an inner class fails Created: 23/Mar/11  Updated: 08/Apr/11  Resolved: 08/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Refactoring, Search
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Perform an inline rename of the inner class:

class Other {
	class Inner {
		
	}	
	
	Inner i
	
}

There is an exception:

Error
Wed Mar 23 14:15:29 PDT 2011
must specify at least one linked position

java.lang.IllegalStateException: must specify at least one linked position
	at org.eclipse.jface.text.link.LinkedModeModel.enforceNotEmpty(LinkedModeModel.java:534)
	at org.eclipse.jface.text.link.LinkedModeModel.install(LinkedModeModel.java:487)
	at org.eclipse.jface.text.link.LinkedModeModel.forceInstall(LinkedModeModel.java:444)
	at org.codehaus.groovy.eclipse.refactoring.actions.GroovyRenameLinkedMode.start(GroovyRenameLinkedMode.java:192)
	at org.codehaus.groovy.eclipse.refactoring.actions.RenameDispatcherAction.run(RenameDispatcherAction.java:53)
	at org.codehaus.groovy.eclipse.refactoring.actions.GroovyRenameAction.run(GroovyRenameAction.java:44)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:278)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:250)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185)
	at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
	at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508)
	at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1034)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3782)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1398)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1383)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1412)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1408)
	at org.eclipse.swt.widgets.Canvas.sendKeyEvent(Canvas.java:416)
	at org.eclipse.swt.widgets.Composite.keyDown(Composite.java:594)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220)
	at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:1959)
	at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2025)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5047)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:4589)
	at org.eclipse.swt.widgets.Display.applicationProc(Display.java:4666)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:115)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3281)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1384)


 Comments   
Comment by Andrew Eisenberg [ 24/Mar/11 ]

Made a change so that this exception is not thrown, but inner classes are still not able to be refactored. This is a search problem because Inner class references are just not being found.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Well, looks like rename refactoring for Inner classes is broken even when not being used as inline renaming. It is likely because the name of the inner class is different from what is used as text.

eg, ClassNode.getName() for Inner defined above is Outer$Inner. This needs to be handled appropriately.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

This is also a problem for general search as well as find occurrences.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

OK. First bit of this is now committed. Inner classes can now be found using find occurrences.

Still need to work on the search.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

I did need to change a bit how import statements are handled by the inferencing visitor, so this may cause some other tests to fail. Will pick up the pieces if this happens.

Comment by Andrew Eisenberg [ 08/Apr/11 ]

All components of this are now completed, tested and committed. Closing this bug.





[GRECLIPSE-1022] Cannot undo a rename of a compilation unit Created: 23/Mar/11  Updated: 24/Mar/11  Resolved: 24/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Rename this class to User2222:

class User {
	String name
	Date age
}

And then undo. The result should be identical before and after, but it is actually:

class UserString name
	Date age
}

It looks like the replace range is incorrect. See CopyResourceElementsOperation.



 Comments   
Comment by Andrew Eisenberg [ 24/Mar/11 ]

The problem is that the TypeReferenceSearchRequestor was returning the type declaration itself as a search match. In most cases, this doesn't matter since it is appropriately filtered out, but in the case of renaming compilation units this is a problem. The renaming of CUs happens in 2 stages. First, renaming all of the type references, and then renaming of the CompilationUnit itself. So, the problem is that the extra search match is being renamed in the first stage and then a second time in the second stage. This is confusing the Undo manager.

The fix is to simply not return these matches from the search requestor.

This change will likely break some other tests, but I will commit it and see what I need to fix later.

Comment by Andrew Eisenberg [ 24/Mar/11 ]

Fixed.





[GRECLIPSE-1021] Syntax coloring initially ignores imported preferences Created: 23/Mar/11  Updated: 11/Apr/11  Resolved: 11/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor, Formatting
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Minor
Reporter: Brian Schmoll Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File schmolly-jira.epf    
Number of attachments : 1

 Description   

I have an export of preferences for Eclipse, which I import whenever I create a new workspace. These preferences include a custom color scheme. When initially opening a .groovy file in the Groovy editor in the new workspace the color scheme matches the default colorings for the Groovy Editor and not my imported preferences. If I navigate to the Groovy Editor Color Preferences page all of the imported preferences are selected as if they are the ones which should be used. If I click "Apply" and reopen my .groovy file then the imported preferences are used.



 Comments   
Comment by Andrew Eisenberg [ 07/Apr/11 ]

I have just tried to reproduce your problem but could not. The imported color preferences are being properly applied without my needing to press apply on the preferences page or reopen the editor.

There may be something about the preferences that you have exported. Could you perhaps attach your epf file here so I can try with that one?

Comment by Brian Schmoll [ 11/Apr/11 ]

Ok. I attached an epf which was able to reproduce the issue. I also tested it and found it only occurs in a specific scenario:

1. Create workspace
2. Launch Eclipse/STS
3. Switch to Grails Perspective
4. Import Preferences file
5. Open Groovy file

On my computer this is when the color scheme gets ignored and clicking apply fixes the issue. I've tried opening a groovy file in the initial java perspective and it applied the colors correctly.

Comment by Andrew Eisenberg [ 11/Apr/11 ]

Thanks for the attachment. I'll try this out.

Comment by Andrew Eisenberg [ 11/Apr/11 ]

OK...thanks for the steps to reproduce and for the epf file. I wasn't quite trying to recreate as you had described, but now I do see the problem.

There are some situations where the settings are being applied properly for me, but others where it is not. This is why I couldn't reproduce earlier.

  1. If a groovy file is already open and settings are imported ---> settings applied properly
  2. If settings are imported when no editors are open and then there is a restart ---> settings applied properly on restart

The only way that I could reproduce is to:

  1. close all editors
  2. import settings
  3. open groovy editor.

So I can now have a deeper look, but it does seem that the problem is slightly less severe than before.

Comment by Andrew Eisenberg [ 11/Apr/11 ]

I see the problem now. We refresh the editor color preferences only in two circumstances:

  1. When a user clicks OK or Apply on the Groovy Editor preference page.
  2. On start up.

This will obviously miss the case when preferences are imported. And it explains the behavior that we are both seeing.

Comment by Andrew Eisenberg [ 11/Apr/11 ]

OK. Fix has been committed. Now, cached groovy editor color preferences will be expunged when preferences are imported.

Digging into this is showing me that this whole area of preferences management is a bit messy especially when preferences change while an editor is already open. We should be managing this better and following what JDT does more closely. I'll raise another bug for that.





[GRECLIPSE-1020] "Run as Groovy" options not available in Groovy project on STS 2.6 Created: 22/Mar/11  Updated: 22/Mar/11  Resolved: 22/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: James Lang Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.6.0.2 on Fedora 13, Vaio F12


Number of attachments : 0

 Description   

In a new Groovy project when right-clicking a Groovy file, there is no Run as Groovy Script option (only Aspect/Java application). I have tried changing to all available perspectives (spring,java,javaEE,grails) to no avail.

In Grails projects right-clicking a groovy file gives Aspect/Java = 3 Grails specific run as options.

I seem to recall run as Groovy options existing pre-STS 2.5, what has changed, am I the only one affected here? My fingers are dearly sore testing in groovyConsole, no autocomplete, backspace in spaces instead of tabs (arggghh), etc.

How can I get run as Groovy options back in place for Groovy projects?? Everything else works fine in STS with Groovy, great autocomplete, syntax checking, etc.

Please save my aching fingers!!



 Comments   
Comment by Andrew Eisenberg [ 22/Mar/11 ]

What is the file that you are trying to run? Is the file a groovy script?

The Run As Groovy Script option only appears when the file is a true script (ie- no explicit main method and statements are defined outside of a class definition).

Comment by Andrew Eisenberg [ 22/Mar/11 ]

Can you please attach a file where you would expect a Run as Groovy Script option, but do not see it?

Comment by James Lang [ 22/Mar/11 ]

Andrew,

yes, I have been attempting to run groovy test classes vs. plain scripts.

Interestingly, if you do add a main method to a class then the run as groovy options DO appear; however, in order to combine class definition with statements outside of the class (i.e. actually get output from "run as" groovy), the class name must be different than the file name.

// Foo.groovy
class Foo {}
println "hey"

error: duplicate class definition (class and script same name); also no "run as" groovy unless add main method.

// Foo.groovy
class Bar {}
println "hey"

works fine, "run as" groovy options appear and can define statements outside class scope.

Not sure if this is a bug, or just Groovy.lang restrictions (with class/script name issue) which STS has no control over.

Comment by Andrew Eisenberg [ 22/Mar/11 ]

Your first example is indeed a groovy issue and this is expected. When you create a script, it implicitly defines a class that has the same name as the file name. So, what you did was define a second class named Foo and this causes a compile problem.

Do you have another example of a script that you would like to run, but can't?

I do see that this code cannot be run as a groovy script, but it can be run as a JUnit test case:

class A extends GroovyTestCase {
	public void testYYY() throws Exception {
		
	}
}

Is this a problem for you?

Comment by James Lang [ 22/Mar/11 ]

Andrew, for testing I can create a plain script that imports tests to run, so not a deal breaker.

The huge win here is that I can code in STS and run via groovy console, thus saving my fingers from working in groovy console itself, which, while nice to have, is terribly inefficient (no code completion, no backspace in tabs, and other madness)

BTW, STS is a wonderful Java/Groovy/Grails IDE on Linux, worlds better than IntelliJ, for example, where the GUI is just plain gruesome, could not tolerate spending my days looking at IJ, made me sick ;--(

I'll post back if I encounter any other issues with "run as" groovy, but for now consider it solved, user error ;--)

p.s. looking forward to Groovy 1.8 support, just starting to play around with RC3...

Thanks for the great work!

Comment by Andrew Eisenberg [ 22/Mar/11 ]

Thanks for getting back to me. Expect 1.8 support momentarily.





[GRECLIPSE-1018] Eclipse lockup on recursive class definition, reproducible. Created: 21/Mar/11  Updated: 21/Mar/11  Resolved: 21/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2RC1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Matthias Gaertner Assignee: Unassigned
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows, Eclipse Helios, Groovy-Eclipse Feature 2.1.2.xx-20110310-1500-e36


Number of attachments : 0

 Description   

Create a trivial class Anything that extends itself
class Anything extends Anything {}
Open this file in Eclipse as a groovy file. Eclipse locks up.

This also "works" recursively, i.e. when extending a class DerivedFromAnything that depends on "Anything"already.

Workaround:
Re-start Eclipse, "Open With..." the offending file in TEXT editor (not Groovy Editor), break the recursion by renaming, save and close the file, re-open with Groovy editor.

If even that does not work, close Eclipse and use an external editor.



 Comments   
Comment by Andy Clement [ 21/Mar/11 ]

Duplicate of GRECLIPSE-531





[GRECLIPSE-1017] java.lang.NoClassDefFoundError: org/codehaus/groovy/eclipse/GroovyLogManager Created: 17/Mar/11  Updated: 17/Mar/11  Resolved: 17/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Bug Priority: Blocker
Reporter: Georg Kallidis Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Helios Service Release 2 Build id: 20110301-1815, windows 32bit


Number of attachments : 0

 Description   

I have installed for Eclipse Helios Service Release 2 Build id: 20110301-1815

Groovy-Eclipse Feature 2.1.2.xx-20110310-1500-e36 org.codehaus.groovy.eclipse.feature.feature.group
Groovy-Eclipse JDT Patch Sources Feature 2.1.2.xx-20110310-1500-e36 org.codehaus.groovy.jdt.patch.source.feature.group
Groovy-Eclipse Sources Feature 2.1.2.xx-20110310-1500-e36 org.codehaus.groovy.eclipse.feature.source.feature.group

and get this error, when I try to view a groovy file

java.lang.NoClassDefFoundError: org/codehaus/groovy/eclipse/GroovyLogManager
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:373)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:252)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:238)
at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:193)
at org.eclipse.jdt.internal.core.JavaElement.getChildrenOfType(JavaElement.java:207)
at org.eclipse.jdt.internal.core.CompilationUnit.getTypes(CompilationUnit.java:932)
at org.eclipse.jdt.internal.core.NameLookup.<init>(NameLookup.java:185)
at org.eclipse.jdt.internal.core.JavaProjectElementInfo.newNameLookup(JavaProjectElementInfo.java:346)
at org.eclipse.jdt.internal.core.JavaProject.newNameLookup(JavaProject.java:2287)
at org.eclipse.jdt.internal.core.JavaProject.newNameLookup(JavaProject.java:2297)
at org.eclipse.jdt.internal.core.JavaProject.findType(JavaProject.java:1326)
at org.eclipse.jdt.internal.core.JavaProject.findType(JavaProject.java:1233)
at org.eclipse.jst.jsp.core.internal.taglib.TaglibHelper.validateTagClass(TaglibHelper.java:857)
at org.eclipse.jst.jsp.core.internal.taglib.TaglibHelper.getCustomTag(TaglibHelper.java:273)
at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.addStartTagVariable(JSPTranslator.java:957)
at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.addTaglibVariables(JSPTranslator.java:906)
at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateXMLNode(JSPTranslator.java:1479)
at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateRegionContainer(JSPTranslator.java:1352)
at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translate(JSPTranslator.java:1127)
at org.eclipse.jst.jsp.core.internal.java.JSPTranslationAdapter.getJSPTranslation(JSPTranslationAdapter.java:153)
at org.eclipse.jst.jsp.core.internal.validation.JSPJavaValidator.performValidation(JSPJavaValidator.java:309)
at org.eclipse.jst.jsp.core.internal.validation.JSPJavaValidator.validateFile(JSPJavaValidator.java:406)
at org.eclipse.jst.jsp.core.internal.validation.JSPValidator.validate(JSPValidator.java:196)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ReconcileStepForValidator.validate(ReconcileStepForValidator.java:292)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ReconcileStepForValidator.reconcileModel(ReconcileStepForValidator.java:258)
at org.eclipse.jface.text.reconciler.AbstractReconcileStep.reconcile(AbstractReconcileStep.java:95)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ValidatorStrategy.reconcile(ValidatorStrategy.java:267)
at org.eclipse.wst.sse.ui.internal.reconcile.DocumentRegionProcessor.process(DocumentRegionProcessor.java:303)
at org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor.process(StructuredRegionProcessor.java:248)
at org.eclipse.wst.sse.ui.internal.reconcile.DirtyRegionProcessor.run(DirtyRegionProcessor.java:667)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

additional note: I could not find this class in http://svn.codehaus.org/groovy/eclipse/trunk/src



 Comments   
Comment by Andrew Eisenberg [ 17/Mar/11 ]

That file keeps track of interesting Groovy events in the workspace and potentially spits them out to the Groovy Event Console. I am not sure why your installation cannot find the class as it is a standard part of Groovy-Eclipse 2.1.2. It may be that your Groovy-Eclipse installation is corrupted. It looks like the org.codehaus.groovy bundle is not properly installed.

The first thing that I would do is to look at the error log. Do you see any relevant errors there?

Then, I would try to uninstall and reinstall Groovy-Eclipse. If that doesn't help you, then we can dig a little deeper.

FYI: the file exists here:

https://svn.codehaus.org/groovy/eclipse/trunk/base/org.codehaus.groovy/src-trace/org/codehaus/groovy/eclipse/GroovyLogManager.java

and here (in the 16 compiler):

https://svn.codehaus.org/groovy/eclipse/trunk/base/org.codehaus.groovy16/src-trace/org/codehaus/groovy/eclipse/GroovyLogManager.java

Comment by Georg Kallidis [ 17/Mar/11 ]

sorry, you are right.
Uninstalling and reinstalling did it on Version: Helios Service Release 2
Build id: 20110301-1815. I had previously org.codehaus.groovy.eclipse.feature_2.0.2 installed...this could be the reason. thanks!

Comment by Andrew Eisenberg [ 17/Mar/11 ]

Thanks for getting back to me on this. Closing the bug.





[GRECLIPSE-1016] Can't install Groovy Plugin for eclipse 3.6 on Vista 64bit Created: 16/Mar/11  Updated: 29/Apr/11  Resolved: 29/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Son Nguyen Assignee: Andrew Eisenberg
Resolution: Cannot Reproduce  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Number of attachments : 0

 Description   

When installing groovy plugin for eclipse 3.6 (Helios) on my Vista 64 bit, I got this error:

An error occurred while collecting items to be installed
session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
Artifact not found: osgi.bundle,org.eclipse.jdt.core,3.6.2.xx-20110310-1500-e36.
http://dist.springsource.org/release/GRECLIPSE/e3.6/plugins/org.eclipse.jdt.core_3.6.2.xx-20110310-1500-e36.jar
Artifact not found: osgi.bundle,org.codehaus.groovy,1.7.8.xx-20110310-1500-e36.
http://dist.springsource.org/release/GRECLIPSE/e3.6/plugins/org.codehaus.groovy_1.7.8.xx-20110310-1500-e36.jar
Artifact not found: osgi.bundle,org.eclipse.jdt.core.source,3.6.2.xx-20110310-1500-e36.
http://dist.springsource.org/release/GRECLIPSE/e3.6/plugins/org.eclipse.jdt.core.source_3.6.2.xx-20110310-1500-e36.jar
Artifact not found: osgi.bundle,org.eclipse.jdt.groovy.core,2.1.2.xx-20110310-1500-e36.
http://dist.springsource.org/release/GRECLIPSE/e3.6/plugins/org.eclipse.jdt.groovy.core_2.1.2.xx-20110310-1500-e36.jar



 Comments   
Comment by Andrew Eisenberg [ 16/Mar/11 ]

There was a temporary problem with the update site. It should be working now. If you continue to have problems, then you can try the milestone update site:

http://dist.springsource.org/milestone/GRECLIPSE/e3.6/

This site currently contains the same bits as the release update site. Please let me know if this works for you.

Comment by Andrew Eisenberg [ 18/Mar/11 ]

Any update on this?

Comment by Andrew Eisenberg [ 29/Apr/11 ]

Assuming fixed since haven't heard back. Please reopen if you continue to have problems.





[GRECLIPSE-1015] Provide UI for switching compiler levels Created: 16/Mar/11  Updated: 07/Apr/11  Resolved: 07/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration, Project Settings, User Interface
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

We've been through this before, but now we need to revisit the issue since we will be soon supporting Groovy 1.8.

We need an easy way for users to switch compiler levels. Ideally, a restart shouldn't be necessary, but I don't think that's possible.



 Comments   
Comment by Andrew Eisenberg [ 16/Mar/11 ]

I have a prototype in my workspace. This prototype works similarly as the compiler switching did before, with a couple of changes so that things seem smoother. Now, as before, we disable the undesired Groovy compiler version, and enable the desired version. However, now we do not try to stop the bundle before restarting. Disabling appears to be sufficient.

I tried this on windows and mac and this is working. However, we need to be careful since in the past it would work for some users, but inexplicably not work for others.

I will commit this change and try to get others to use it.

Comment by Andrew Eisenberg [ 16/Mar/11 ]

Now tried it out on Linux and it is working there, too. However, this is only in a runtime workspace. I will wait for the build to come out and see if it is working in a full build.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Now available and working.





[GRECLIPSE-1014] strange highlighting Created: 16/Mar/11  Updated: 11/Apr/11  Resolved: 11/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Bug Priority: Minor
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

in this groovy class:

class C {
  int i = 0xff;
}

the '0' is a different colour to the xff



 Comments   
Comment by Andrew Eisenberg [ 16/Mar/11 ]

Hmmm...our syntax highlighter does not take into account this kind of syntax. Definitely a bug.

Comment by Andrew Eisenberg [ 16/Mar/11 ]

Try to get this in for 2.1.3. I don't think it will be particularly difficult.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Not as easy as I would have thought. There is no pre-existing scanner rule in JDT for all variants of number literals.

Our best bet might be to do this using semantic highlighting.

Comment by Andrew Eisenberg [ 07/Apr/11 ]

Fixed now with regression tests.

Comment by Andrew Eisenberg [ 11/Apr/11 ]

Now fixed.





[GRECLIPSE-1013] Incorrectly underlining 'text' Created: 15/Mar/11  Updated: 11/Apr/11  Resolved: 11/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Number of attachments : 0

 Description   
package org.grails.shortenurl

class TinyUrl{
  static String shorten(String longUrl){
    def addr = "http://tinyurl.com/api-create.php?url=${longUrl}"
    return addr.toURL().text
  }
}

In that sample 'text' is underlined, whereas it actually maps onto DGM.getText(URL). Changing it to getText() it is no longer underlined.



 Comments   
Comment by Andrew Eisenberg [ 18/Mar/11 ]

Closed accidentally. Re-opening now.

Comment by Andrew Eisenberg [ 11/Apr/11 ]

Fixed locally both for type inferencing and for content assist. Will create some tests before committing.

Comment by Andrew Eisenberg [ 11/Apr/11 ]

Fix committed with regression tests.





[GRECLIPSE-1012] Extra phase operation in CompilationUnit is preventing DSL support from working Created: 15/Mar/11  Updated: 28/Mar/11  Resolved: 28/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Task Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There is a pair of phase operations added in CompilationUnit that is interfering with DSL support (near line 190):

addPhaseOperation(resolve, Phases.SEMANTIC_ANALYSIS);
addPhaseOperation(staticImport, Phases.SEMANTIC_ANALYSIS);

Comment out the first line and DSL support is working. Uncomment it out and it is failing. It has something to do with the resolver being cleaned up a bit after the first time it is used.



 Comments   
Comment by Andy Clement [ 28/Mar/11 ]

The JDTResolver tracks the 'active scope' - the scope for the file which it is currently resolving. You are relying on an accidental side effect right now, that the scope isn't cleared at the end of resolution. The reason it makes a difference when double resolution happens is that in that case the second resolution nulls the active scope before determining what it would be then it discovers the file has already been resolved and exits immediately. With a single resolve the scope is left as whatever file was last processed and not cleared again.

I'll adjust the scope clearing to enable you to progress but I'm not sure, longer term, that we want to resolve types like this. But I don't have enough time to architect the right way at the moment.





[GRECLIPSE-1011] BadLocationException when trying to rename a non-getter variant of a getter method Created: 14/Mar/11  Updated: 14/Mar/11  Resolved: 14/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Given this code:

class Result {
	def getVal2() {
		
	}
}

def res = new Result()
res.val2

Invoke rename on either the getVal2 declaration or the val2 reference this exception comes out:

org.eclipse.jface.text.BadLocationException: First position: 'getVal2' at 72, this position: 'val2' at 179
	at org.eclipse.jface.text.link.LinkedPositionGroup.enforceEqualContent(LinkedPositionGroup.java:132)
	at org.eclipse.jface.text.link.LinkedPositionGroup.addPosition(LinkedPositionGroup.java:113)
	at org.codehaus.groovy.eclipse.refactoring.actions.GroovyRenameLinkedMode.start(GroovyRenameLinkedMode.java:172)
	at org.codehaus.groovy.eclipse.refactoring.actions.RenameDispatcherAction.run(RenameDispatcherAction.java:53)
	at org.codehaus.groovy.eclipse.refactoring.actions.GroovyRenameAction.run(GroovyRenameAction.java:44)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:278)
...

I need to filter out all references that are not exactly the same string value as the declaration.



 Comments   
Comment by Andrew Eisenberg [ 14/Mar/11 ]

Fixed locally. Just filter out the occurrences that do not have the correct source length.





[GRECLIPSE-1010] Ability to rename refactor getter and setter variants of property references Created: 14/Mar/11  Updated: 14/Oct/11  Resolved: 14/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.6.0.Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates GRECLIPSE-1205 Refactoring of synthetic getters and ... Resolved
Number of attachments : 0

 Description   

Given this code:

class Result {
	def val  = 9
}

new Result().getVal()
new Result().setVal(0)

It would be nice to have getVal and setVal properly renamed when val is renamed.

This will probably require a refactoring participant and this kind of rename will not show up in inline renaming.



 Comments   
Comment by Andrew Eisenberg [ 14/Oct/11 ]

GRECLIPSE-1205 is now fixed and so is this issue.





[GRECLIPSE-1009] error message on wrong line Created: 14/Mar/11  Updated: 14/Oct/11  Resolved: 06/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.0Release

Type: Bug Priority: Minor
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

class Result {
def val2 = 9
def doOperation()

{ "$[val2" }

}

error on doOperation() lineb



 Comments   
Comment by Andrew Eisenberg [ 06/May/11 ]

This does not seem to be a problem any more after the upgrade to 1.7.10. OK to close?





[GRECLIPSE-1008] Spurious warning when rename refactoring field reference inside of closure Created: 14/Mar/11  Updated: 15/Mar/11  Resolved: 15/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Inside of this code:

class Result {
	def val
	def doOperation= {
		 val
	}
}

Perform rename refactor on val. And after committing the refactoring change, the processor comes up with a warning:

The reference to val2 will be shadowed by a renamed declaration.

This is happening because we are visiting the closure expression twice when looking for references. The first time as part of the field declaration and the second time as part of the default constructor (groovy stuffs field initializers into the default constructor). So, we need to be more careful about visiting here.

Just to note, if the user clicks Continue the refactoring completes as expected with no errors.



 Comments   
Comment by Andrew Eisenberg [ 14/Mar/11 ]

I think the solution here is as simple as not visiting the field initializer directly from the inferencing engine. Let the visit happen indirectly when the default constructor is visited. However, I'm not confident enough yet that this won't fail under certain situations such as when there is an existing default constructor.

Comment by Andrew Eisenberg [ 14/Mar/11 ]

It's a little more complicated than what I describe above. I also need to take into account initializers (both static and non-static).

Comment by Andrew Eisenberg [ 15/Mar/11 ]

The problem is that field initializers are copied to one or more constructors. The constructors that they are copied to are the base constructors (ie- the constructors that don't call any other constructors in the class). Also, object initializers are copied as well using the same heuristics. But, they are also removed from the class.

Rather than trying to do some really smart visitation so that each statement is visited exactly once, a simpler approach would be to visit the entire AST (duplicates and all). But, ensure that the requestor does not accept duplicates.

Comment by Andrew Eisenberg [ 15/Mar/11 ]

Fix committed with regression tests.





[GRECLIPSE-1007] Method breakpoints not working Created: 14/Mar/11  Updated: 14/Mar/11  Resolved: 14/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This is just a place holder to remember that method breakpoints were not working properly for the 2.1.2 release and so they have been removed. But, they are working now and will be reintroduced for the 2.1.3 release.



 Comments   
Comment by Andrew Eisenberg [ 14/Mar/11 ]

already fixed.





[GRECLIPSE-1005] bodyStart field of method declarations Created: 13/Mar/11  Updated: 14/Oct/11  Resolved: 14/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.bodyStart field is not being calculated correctly. We are just setting it to the value of MethodNode.getNameEnd(). This approximate value has been sufficient so far, but with 3.7 support, we need to be more precise in order to get certain kinds of rename refactoring working (ie- rename refactoring while leaving the delegate behind).

This is the cause of the last two failing tests on e37.

I have a solution locally, but will not commit until I have looked at this more. It seems like the value of MethodNode.getCode().getStart() is the correct value and with it, the tests are passing. But, this kind of change will likely have some wider reaching changes.



 Comments   
Comment by Andrew Eisenberg [ 14/Mar/11 ]

Fixed with regression tests.

I saw that the source location tests were only testing IJavaElements and not DOM AST source locations. So, I made some changes to the testing so that both are being checked.

I did notice a few more places where source locations are not correct, but these don't seem to have any effect on what we are doing. I'll open a new bug for that.





[GRECLIPSE-1004] HttpBuilder "No signature of method" error when run as a Groovy script from within eclipse Created: 12/Mar/11  Updated: 15/May/11  Resolved: 06/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Testing, Running, Debugging
Affects Version/s: 2.1.2RC1
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Trang Nguyen Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
is depended upon by GRECLIPSE-482 GroovyWS script doesnt work when run ... Resolved
Number of attachments : 0

 Description   

This issue was resolved in release 2.0.2 (see GRECLIPSE-705) but has resurfaced in the latest 2.1.2 release:

Caught: groovy.lang.MissingMethodException: No signature of method: groovyx.net.http.HTTPBuilder.request() is applicable for argument types: (groovyx.net.http.Method, com.openmarket.payments.campaign.validation.AuthRequest$_send2_closure1) values: [PUT, com.openmarket.payments.campaign.validation.AuthRequest$_send2_closure1@25071521]
Possible solutions: request(groovyx.net.http.Method, groovy.lang.Closure), request(groovyx.net.http.Method, java.lang.Object, groovy.lang.Closure), request(java.lang.Object, groovyx.net.http.Method, java.lang.Object, groovy.lang.Closure)



 Comments   
Comment by Andrew Eisenberg [ 12/Mar/11 ]

First, what happens when you do Run as -> Java Application?

Also, can you attach a simple script that reproduces the problem?

Comment by Trang Nguyen [ 12/Mar/11 ]


I'm no longer able to repro. Originally, I ran into the exception only when I run the app as a Groovy script or via the console. It runs fine when executed as a java app. Since then, I've recreated my maven eclipse project settings via the eclipse maven plugin, which initializes the project with jars that point to my maven repository. Via the eclipse properties UI, I've also manually added Groovy libraries to the application classpath and moved the Groovy libraries to the top of the "Order and Export" list and this seemed to solve the problem. I can't revert to the original state in which I first ran into the issue - I've tried removing the Groovy libraries from my eclipse build settings and the app runs fun (as groovy script as well as java app). I'm going to go ahead and close the defect!

Comment by Andrew Eisenberg [ 12/Mar/11 ]

Thanks for getting back to me and feel free to reopen if you see this again.

Comment by jm [ 04/Apr/11 ]

I am hitting this in Version: 2.1.2.xx-20110310-1500-e36
So is it really an issue in greclipse or not?
Any workaround?

Comment by Andrew Eisenberg [ 04/Apr/11 ]

Reopening

Comment by Andrew Eisenberg [ 04/Apr/11 ]

jm...please provide some more detail:

  1. How do you run the script? As a Groovy script or a Java app?
  2. Try running using the other mechanism (they both should work, but this would help narrow down the problem).
  3. And the script itself would be useful.
Comment by jm [ 06/Apr/11 ]

1. How do you run the script? As a Groovy script or a Java app?
I see what original reporter says. Works as java app, does not as groovy script

The script is too cumbersome...anyway as I can run it as a java app is not a showstopper anymore.

Comment by Andrew Eisenberg [ 06/Apr/11 ]

OK. I will resolve this issue again, but please re-open if you see any more problems.

Comment by Alexis Kinsella [ 14/May/11 ]

Hi, I get same issue with GRECLIPSE 2.5 and "Run as Groovy Script". Here is the script:

import groovyx.net.http.HTTPBuilder
import static groovyx.net.http.Method.GET
import static groovyx.net.http.ContentType.TEXT

// initialze a new builder and give a default URL
def http = new HTTPBuilder( 'http://www.google.com/search' )

http.request(GET,TEXT) { req ->
uri.path = '/mail/help/tasks/' // overrides any path in the default URL
headers.'User-Agent' = 'Mozilla/5.0'

response.success = { resp, reader ->
assert resp.status == 200
println "My response handler got response: $

{resp.statusLine}

"
println "Response length: $

{resp.headers.'Content-Length'}

"
System.out << reader // print response reader
}

// called only for a 404 (not found) status code:
response.'404' =

{ resp -> println 'Not found' }

}

I get this error:

Caught: groovy.lang.MissingMethodException: No signature of method: groovyx.net.http.HTTPBuilder.request() is applicable for argument types: (groovyx.net.http.Method, groovyx.net.http.ContentType, GoogleTest$_run_closure1) values: [GET, text/plain, GoogleTest$_run_closure1@74d402dd]
Possible solutions: request(groovyx.net.http.Method, groovy.lang.Closure), request(groovyx.net.http.Method, java.lang.Object, groovy.lang.Closure), request(java.lang.Object, groovyx.net.http.Method, java.lang.Object, groovy.lang.Closure)
at GoogleTest.run(GoogleTest.groovy:8)


Please reopen

Comment by Andrew Eisenberg [ 15/May/11 ]

Hi Alexis,

I think the problem that you are having (as well as the previous commenters) is summarized in GRECLIPSE-1055 and GRECLIPSE-482. My guess is that the hardwired paths in your launch configuration are no longer working since you upgraded. The workaround is to delete the launch configuration and create a new one for the new version of groovy. However, the real fix would be to address the problem specified in GRECLIPSE-1055.

If this does not fix your problem, then I'll reopen this issue and have a deeper look.





[GRECLIPSE-1003] CompilationUnit cannot be cast to GroovyCompilationUnit Created: 10/Mar/11  Updated: 10/Mar/11  Resolved: 10/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Michal Eibl Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP
Eclipse EE 3.6.2 + Installed plugins: Subclipse, Checkstyle, Findbugs, JBoss Tools, Object Aid - Class Diagram,
GrEclipse 2.1.1


Number of attachments : 0

 Description   

When creating new groovy class, an error message appears:

Creation of element failed.

org.eclipse.jdt.internal.core.CompilationUnit cannot be cast to
org.codehaus.jdt.groovy.model.GroovyCompilationUnit

Eclipse Log file:

java.lang.ClassCastException: org.eclipse.jdt.internal.core.CompilationUnit cannot be cast to org.codehaus.jdt.groovy.model.GroovyCompilationUnit
at org.codehaus.groovy.eclipse.wizards.NewClassWizardPage.createType(NewClassWizardPage.java:129)
at org.codehaus.groovy.eclipse.wizards.NewClassWizard.finishPage(NewClassWizard.java:64)
at org.eclipse.jdt.internal.ui.wizards.NewElementWizard$2.run(NewElementWizard.java:117)
at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4777)
at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)



 Comments   
Comment by Michal Eibl [ 10/Mar/11 ]

It seems to be connected with GRECLIPSE-602, but it ought to be resolved.

Comment by Michal Eibl [ 10/Mar/11 ]

JDK 1.6.0.24

Comment by Andy Clement [ 10/Mar/11 ]

Unfortunately, 2.1.1 is not compatible with Eclipse 3.6.2. Please install a recent dev build - the 3.6.2 based release (2.1.2) will be out shortly. Snapshot update site is: http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

Comment by Andrew Eisenberg [ 10/Mar/11 ]

This is unlikely to be related to GRECLIPSE-602. And as Andy mentions, please upgrade to the latest snapshot it is fixed in that version. Let us know if this fixes your problem.

Comment by Michal Eibl [ 10/Mar/11 ]

Yes, the snapshot works fine. Thank you .

Comment by Andrew Eisenberg [ 10/Mar/11 ]

Thanks for getting back to us. Closing this issue.





[GRECLIPSE-1001] Two Groovy types with the same name and package, but in different source folders should be an error Created: 03/Mar/11  Updated: 07/Mar/11  Resolved: 07/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Unassigned
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
  1. Create a default groovy project
  2. Add a second source folder
  3. Add a Java class to one source folder and a second Java class with same name and package in the second source folder.
  4. Java compilation problem: "The type AAAA is already defined"
  5. Now, do the same for 2 Groovy classes.
  6. No compilation problems.

When there is 1 Java class and 1 Groovy class with the same name and package, the Java class has an error, but not the groovy class.

Perhaps this is required behavior since some kinds of Groovy projects expect source folders to be compiled separately.



 Comments   
Comment by Kris De Volder [ 07/Mar/11 ]

If you created unit and integration tests for the same domain class, I think they would have the same exact fully qualified name

Comment by Andy Clement [ 07/Mar/11 ]

Although some build systems can cope with different source folders containing files that have the same name (and package prefix) - Eclipse cannot, so if you cause that scenario to occur using grails, it will not build inside eclipse where it might build outside. (There is an ancient bug about supporting this in eclipse).

The original reason for this bug is not a groovy-eclipse issue, it is a base eclipse issue. It occurs on an incremental compile of one of the duplicates - the error message can be lost. I believe because the incremental compile state can't work out that it needed to rebuild the other file to determine there was a dup.

Comment by Andy Clement [ 07/Mar/11 ]

Not a groovy-eclipse bug





[GRECLIPSE-1000] GroovyExtraInformationHover will not delegate to other hovers Created: 03/Mar/11  Updated: 18/Mar/11  Resolved: 18/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Number of attachments : 0

 Description   

When there is a process paused at a breakpoint typically, the variable values hover will be invoked to show the value of a field or local variable.

However, due to the ordering of the hover extensions coming from the platform, the variable values hover never runs when a GroovyExtraInformationHover returns non-null information.

There should be a way to ensure that the variable values hover still gets a chance to run.



 Comments   
Comment by Andrew Eisenberg [ 18/Mar/11 ]

Working now. Will commit soon.





[GRECLIPSE-999] generics handling incorrect, affects gpp Created: 03/Mar/11  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.7.2.Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This is a distilled example of the problem:

import java.lang.ref.WeakReference
import java.util.concurrent.ConcurrentHashMap

@Typed class WeakValueMap<K2,V2> extends ConcurrentHashMap<K2,WeakValueMap.WV<V2>> {\n"+
  static class WV<VV> extends WeakReference<VV> {
  }
}

@Typed class Foo {
	private final WeakValueMap<String,Class> cache
	public x(String name) {
		def res = cache.get(name).get()
		foo(res)\n"+
	}
	public void foo(Class c) {
	}
}

If you compile that and use the groovy++ ast transform (I was on 0.4.170) it will give you an error that it can't find the method foo(Object) - the type of res has been incorrectly inferred. It should be Class but the representation of generics that groovy-eclipse builds is slightly different to that built by plain groovyc, and this causes the inferencing breakdown.



 Comments   
Comment by Andy Clement [ 28/Nov/12 ]

possibly fixed with recent changes to generics handling but we aren't really testing with gpp any more.





[GRECLIPSE-998] As a user, I want to be able to add inferencing suggestions through the UI. Created: 02/Mar/11  Updated: 29/Sep/11  Resolved: 29/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine, User Interface
Affects Version/s: 2.1.1Release
Fix Version/s: 2.5.2.Release

Type: New Feature Priority: Major
Reporter: Andrew Eisenberg Assignee: Nieraj Singh
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Sometimes when a reference is underlined in the editor, the actual type of that reference is known by the user, but Groovy-Eclipse has no hints to help it infer the type.

There should be a mechanism by which a user can add inference suggestions through the UI.

For example, if a reference is inferred as UNKNOWN and it is underlined, then there should be a quick assist available that brings up a dialog where the user can enter the type and declaring type of that reference. Also, the user should be able to specify whether it is a property or a method (and if a method, parameter names and types). Finally, there should be a field for extra documentation that will appear when the reference is hovered on.

These references should be able to be added per-project, or in the workspace as a whole.

There should also be a preference page (both in groovy projects and in the workspace as a whole), where all user-suggestions will be stored. The user should be able to edit, delete, and add new suggestions.



 Comments   
Comment by Andrew Eisenberg [ 26/Jul/11 ]

UI component of this work is now committed

Comment by Andrew Eisenberg [ 29/Sep/11 ]

complete.





[GRECLIPSE-997] Inferencing problem with generics Created: 02/Mar/11  Updated: 22/Mar/11  Resolved: 22/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Number of attachments : 0

 Description   

In the snippet below, MyMap.get() should be inferred as the get() method on WeakReference, but it isn't.

//@Typed
class RemoteMessageChannel<M extends Serializable> {// extends MessageChannel<M> {

//	static class MyMap<K,V> extends HashMap<K,WeakReference<V>> {
	
	static class MyMap extends HashMap<String,WeakReference<Class>> {	
//		V putIfNotYet(K key, V value) {
			
	
//		}
	}
	MyMap cache;
	
	void receiveBytes(String name) {
		ClassLoader parent
		if (name == this.class.name)
			this.class
		else { 
			def res = cache.get(name)?.get()
			if (res == this.class)
				throw new ClassNotFoundException()
			if (!res) {
				try {
					res = parent.loadClass(name)
				}
				catch (ClassNotFoundException e) {
					cache.putIfNotYet(name, this.class)
					throw e
				}
				cache.putIfNotYet(name, res)
			}
//			return res
		}
	}
	
}


 Comments   
Comment by Andrew Eisenberg [ 03/Mar/11 ]

Here is a simpler variant of the problem:


class MyMap extends HashMap<String,WeakReference<Class>> {	 }
MyMap cache;

HashMap<String,WeakReference<Class>> other

cache.get(name).get()  // underlined
other.get(name).get()  // not underlined
Comment by Andrew Eisenberg [ 03/Mar/11 ]

Even simpler:

class MyMap extends HashMap<String,Class> {	 }
MyMap cache;
cache.get("")

The problem is that the GenericsNode}}s on the ClassNode for the cache variable's declaration is null and references to methods on HashMap that should know about the type parameters do not have them resolved. However, when looking at {{HashMap, the type parameters are placed correctly.

What I think needs to happen is that some better awareness of Generics are required for the inferencing engine. Currently, the inferencing engine assumes that all type parameters are declared in the lowest level type and instanciated in the variable declaration. This solves the common case like this:

List<String> foo

However, when the type variables are instantiated in a subtype and a variable is declared without direct mention of the type variable (as in the example), the inferencing engine cannot find the type variable and so assumes that no generic types are involved.

We need to ensure that the inferencing engine knows about all type variables an how they are instantiated.

Comment by Andrew Eisenberg [ 03/Mar/11 ]

See SimpleTypeLookup.typeFromDeclaration().

Comment by Andrew Eisenberg [ 18/Mar/11 ]

Progress...I have something working in my workspace. The logic to capture all generics is very tricky. I'll need to write lots of tests before I can commit.

Comment by Andrew Eisenberg [ 22/Mar/11 ]

No...my solution isn't quite right. When subclasses partially resolve the type parameters of the super class, such as the example originally supplied in this bug report, my current solution isn't working right.

Comment by Andrew Eisenberg [ 22/Mar/11 ]

Wow. This turned out to be a lot more difficult than I had originally thought. I had to completely rewrite the generics resolver code. The good news is that it is less complicated now (even though I am still not happy with it), and also it is more complete.

I am committing this work now with a bunch more tests for it.





[GRECLIPSE-996] new groovy class wizard won't let me create something that clashes with a type on the project classpath Created: 02/Mar/11  Updated: 04/Mar/11  Resolved: 03/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In a groovy project, use the groovy wizard to create a type that exists on the classpath (e.g. java.lang.String) - you will get an error about the type already existing. The java class wizard doesn't have this problem.



 Comments   
Comment by Andrew Eisenberg [ 03/Mar/11 ]

fixed.





[GRECLIPSE-995] Inferencing engine should only visit the relevant portion of the module node if possible Created: 02/Mar/11  Updated: 02/Mar/11  Resolved: 02/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, the inferencing engine will always visit the entire file (until canceled) when trying to infer types. However, there are some operations where this is not necessary. For operations like code select and content assist, where we are interested in the type at a particular offset in the file, we should only visit the method, initializer, or closure where this offset exists.



 Comments   
Comment by Andrew Eisenberg [ 02/Mar/11 ]

Just to be more clear. Content assist and code select speed would be positively affected by this change, particularly for large files.

Comment by Andrew Eisenberg [ 02/Mar/11 ]

This is now committed with regression tests. I don't actually know how much time this saves us on large files. I'll try this out.

Comment by Andrew Eisenberg [ 02/Mar/11 ]

I did some simple analysis. Working in a 1571 line file, I am testing content assist and hovers over a field reference that is near the last line of the file.

For code select, the time is minuscule with and without partial visit support (usually less than 10ms in either case).

For content assist, however, there does appear to be a difference.

Full visit (ms): 829, 406, 407, 373
Partial visit (ms): 479, 283, 258, 251

So, there is a significant speedup for content assist, although not quite half the time.

Unfortunately, though, this is only part of the story. Reconciling and build structure are not part of this calculation. Reconciling seems to cost between 2500 and 6000 ms and dwarfs the time spent on code select and content assist. I am not sure where this time is being spent exactly.

One clarification. Build structure (a slightly more costly variant of reconciling) only occurs after a change to bring the CompilationUnit back into consistency. Reconciling occurs when the editor gains focus. Both of these operations happen in the background. If (and only if) a CompilationUnit is inconsistent, a code select or a content assist operation must wait for the build structure to complete (thus adding 2.5 - 6 seconds onto the cost of the operation). Otherwise, the operation is quite fast.





[GRECLIPSE-993] Hovering to navigate gives NPE Created: 24/Feb/11  Updated: 24/Feb/11  Resolved: 24/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
import groovy.sql.Sql;

import java.util.Date;


class Super {
	def static getSql() {			}
}
 
class Sub extends Super {
	def static Date getDatabaseDate() {
		sql.eachRow("select sysdate as now from dual") {
			print 1
		}     
     }
   
}

trying to navigate to the 'sql' reference in Sub, if I ctrl+hover I get:


java.lang.NullPointerException
	at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createGenericsAwareName(CodeSelectRequestor.java:257)
	at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createUniqueKeyForResolvedClass(CodeSelectRequestor.java:346)
	at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createUniqueKeyForClass(CodeSelectRequestor.java:362)
	at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createUniqueKeyForField(CodeSelectRequestor.java:331)
	at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.createUniqueKey(CodeSelectRequestor.java:299)
	at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.resolveRequestedElement(CodeSelectRequestor.java:211)
	at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectRequestor.acceptASTNode(CodeSelectRequestor.java:123)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleRequestor(TypeInferencingVisitorWithRequestor.java:1460)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleExpression(TypeInferencingVisitorWithRequestor.java:730)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitVariableExpression(TypeInferencingVisitorWithRequestor.java:812)
	at org.codehaus.groovy.ast.expr.VariableExpression.visit(VariableExpression.java:68)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitMethodCallExpression(TypeInferencingVisitorWithRequestor.java:1206)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitReturnStatement(CodeVisitorSupport.java:73)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitReturnStatement(ClassCodeVisitorSupport.java:224)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitReturnStatement(TypeInferencingVisitorWithRequestor.java:1027)
	at org.codehaus.groovy.ast.stmt.ReturnStatement.visit(ReturnStatement.java:47)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:179)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitBlockStatement(TypeInferencingVisitorWithRequestor.java:1012)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:102)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:113)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstructorOrMethod(TypeInferencingVisitorWithRequestor.java:623)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:379)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitJDT(TypeInferencingVisitorWithRequestor.java:226)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitCompilationUnit(TypeInferencingVisitorWithRequestor.java:180)
	at org.codehaus.groovy.eclipse.codebrowsing.requestor.CodeSelectHelper.select(CodeSelectHelper.java:54)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:493)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:485)
	at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.codeSelect(GroovyCompilationUnit.java:480)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaElementHyperlinkDetector.detectHyperlinks(JavaElementHyperlinkDetector.java:67)
	at org.eclipse.ui.texteditor.HyperlinkDetectorRegistry$HyperlinkDetectorDelegate.detectHyperlinks(HyperlinkDetectorRegistry.java:80)
	at org.eclipse.jface.text.hyperlink.HyperlinkManager.findHyperlinks(HyperlinkManager.java:276)
	at org.eclipse.jface.text.hyperlink.HyperlinkManager.mouseMove(HyperlinkManager.java:452)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:205)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3776)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1367)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1390)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375)


 Comments   
Comment by Andrew Eisenberg [ 24/Feb/11 ]

The problem is that the sql reference is being resolved to a field node, but the FieldNode.declaringClass field is null. When this synthetic field is being created, the setDeclaringClass method must be called.

I'm not sure exactly where this field is being created, but I can look deeper.

Comment by Andrew Eisenberg [ 24/Feb/11 ]

I notice that the owner field is correctly populated here. I'm not sure what the difference between owner and declaringClass. In my previous experience, the latter was correct and never null, whereas the former was sometimes incorrect.

Comment by Andrew Eisenberg [ 24/Feb/11 ]

Fixed the issue with regression tests, but not entirely sure that the fix is the right one. I made some changes to ensure that getDeclaringClass never returns null and always returns the class that gives rise to this declaration.

It could be that we should be using getOwner for this purpose.





[GRECLIPSE-992] Unable to spot a property via the getter Created: 23/Feb/11  Updated: 04/Mar/11  Resolved: 24/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.1.2RC1

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

A supertype has a static getter-like method

def static getFoo()

{...}

A subtype attempts to refer to foo

def static m()

{ foo.something }

An incorrect error comes out against the foo reference. This is due to us not finding the getFoo method when looking through methods defined on the supertype, so not determining foo is a property reference.



 Comments   
Comment by Andy Clement [ 24/Feb/11 ]

fixed





[GRECLIPSE-991] A user I *do not* want to see unknown things underlined in my IDE. I Created: 22/Feb/11  Updated: 04/Mar/11  Resolved: 22/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Improvement Priority: Trivial
Reporter: Andries Spies Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Underlined code is really distracting. Groovy is a scripting language, so I do not expect the IDE to know and understand every bit of script I'm writing. What is worse is the fact there are no preference settings to just switch it off.



 Comments   
Comment by Andrew Eisenberg [ 22/Feb/11 ]

Done. Go to Preferences -> Groovy -> Editor and uncheck "Enable semantic highlighting...".

Comment by Andries Spies [ 22/Feb/11 ]

Thanx! Much appreciated





[GRECLIPSE-990] syntax highlighting for a 'method name with spaces in' Created: 21/Feb/11  Updated: 18/Mar/11  Resolved: 18/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.2Release
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Number of attachments : 0

 Description   

Playing with a spock sample of code:

class WorkflowTest extends spock.lang.Specification { 
        def "testing simple Spock Method"(){ 
                expect: 
                        name.size() == length 
                where: 
                        name << ["Kirk", "Spock", "Scotty"] 
                        length << [4,5,6] 
        }  
		 def "testing simple Spock Methaod"(){ 
                expect: 
                        name.size() == length 
                where: 
                        name << ["Kirk", "Spock", "Scotty"] 
                        length << [4,5,6] 
        }  

The last char of the method name and the closing " are in pink, unlike the rest of the method name text.



 Comments   
Comment by Andrew Eisenberg [ 21/Feb/11 ]

I am pretty sure that this is a source location problem.

Comment by Andrew Eisenberg [ 18/Mar/11 ]

The problem is happening here because the AntlrParserPlugin calcuates the name range end based on the nameStart + name.length(). We do this because there are circumstances when the end value of an AST node is incorrect because it includes trailing whitespace.

What this means is that since the name range is based on the length of the text of the name and not the end location of the ast node, we are off by two (since the name text does not include the quotes).

Now, I am trying to reproduce the broken end locations (on 1.8) but can't for method name ranges. I know the problem still exists for binary expressions and variable expressions, but maybe it dpesn't affect name ranges.

Comment by Andrew Eisenberg [ 18/Mar/11 ]

Yes...I do not believe that this invalid end location is possible for method names. So, this is easy enough to work around. I will make the change in both 17 and 18 and get some tests for it.

Comment by Andrew Eisenberg [ 18/Mar/11 ]

Fixed with regression tests. Committed to 17 and 18.





[GRECLIPSE-989] NPE on compiling Groovy code Created: 16/Feb/11  Updated: 16/Mar/11  Resolved: 21/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Alexander Kitaev Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

--8< snipped 8<---


Number of attachments : 0

 Description   

java.lang.NullPointerException
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.getTransformClassNames(ASTTransformationCollectorCodeVisitor.java:101)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.visitAnnotations(ASTTransformationCollectorCodeVisitor.java:164)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:112)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:124)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1103)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.visitClass(ASTTransformationCollectorCodeVisitor.java:63)
at org.codehaus.groovy.transform.ASTTransformationVisitor$1.call(ASTTransformationVisitor.java:187)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1139)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:577)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:555)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:532)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:165)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1848)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:816)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:619)



 Comments   
Comment by Andy Clement [ 16/Feb/11 ]

This looks like we are encountering an unusual (not seen before) ast transform definition. Do you know what AST transforms you are using? They are likely from library jars on your project classpath. Without knowing precisely what is unusual about the transform definition, I'll have to initially just create a debug build and get you to collect whatever comes out.

Comment by Andy Clement [ 17/Feb/11 ]

I've committed some diagnostics so that when this happens we can see the ast transform annotation involved that has the unusual value

Comment by Semyon Vadishev [ 17/Feb/11 ]

In our tests we use custom local AST Transformations. Most probably they cause all the problems with groovy builder.

You may download transformation code and its usage examples from https://github.com/vs/grooby.

1. First type of transformations is quite simple, here its usage example:

https://github.com/vs/grooby/blob/master/grooby/src/org/tmatesoft/grooby/example/InsertHash.groovy

Class InsertHash annotated with @InsertMethodHash(applyToMethodsWith = Transformable, doNotIncludeToHash = Skip)

During the transformation we

a) Enter every method which annotated with @Transformable. That implies that Transformable class has to compiled before running our transformation. E.g. using IntelliJ Idea we put Transformable class into separate module to be sure it is definitely compiled before compiling test sources;

b) Walk through the whole AST of the method collecting its structure information as SHA-1 hash;

c) Do not include into hash calculations those annotations listed at 'doNotIncludeToHash' member. That also implies that Skip class has to be put aside the same way as Transformable;

d) After AST traversal we have SHA-1 hash encoded as 40 hexadecimal characters, we put it into @MethodHash('<hash>') annotation of corresponding method.

This way at runtime we have information on AST structure of the method. We heavily depend on caches so this technique helps us a lot.

2. The example for the second type of transformation is located at

https://github.com/vs/grooby/blob/master/grooby/src/org/tmatesoft/grooby/example/StringCommand.groovy

Class StringCommand has main method which looks like as follows:

@ExecuteString(value = EsExecutableCommand, logger = 'LOGGER')
public static void main(String[] args)

{ "echo Hello there!" }

For that particular case statement

"echo Hello there!"

is being transformed into

EsExecutableCommand.ECHO.execute(null, "Hello there!", LOGGER)

At compile time we're walking through method statements looking for

"generic command <args>"

or

def variable = "generic command <args>"

If statement meets this condition, we check whether String value matches any pattern defined among enum constants specified at the 'value' member of @ExecuteString annotation (value = EsExecutableCommand at the example). If so, we transform String part of the statement into command execution call just like above.

This technique works with GString as well making command execution as easy as running it from shell. It's also extremely helpful for writing our tests.

Certainly we must be sure that EsExecutableCommand class must be available at compile time – we call EsExecutableCommand#matches(String) during the transformation to find enum constant. It's easy to do this trick with default Groovy compiler and IntelliJ Idea compiler (which is default compiler with some compiler results caching, I suppose), but it seems to be impossible with Eclipse Groovy Builder.

Comment by Andy Clement [ 17/Feb/11 ]

Thanks for the links to code. The first thing you are hitting is that you must be the first to use the classes variant in GroovyASTTransformationClass (rather than value):

public @interface GroovyASTTransformationClass {
String[] value() default {};
Class[] classes() default {};
}

As there was no code in Groovy-Eclipse to cope with it (just a placeholder saying we ought to fill it in).

I've now filled in enough to get further. I only created some variant code based on your definitions though, I haven't checked everything out of the repo to see whether it works. The changes I've made should be in a dev build later today.

Comment by Semyon Vadishev [ 17/Feb/11 ]

Thank you for the prompt reply.

Our ultimate goal is to get Eclipse usable for further development ASAP. Currently we have an ugly workaround with ant script compiling the sources instead of Eclipse builder. If you think there could be some changes to our code which workaround existing issues, we'd highly appreciate patches from you. I'd rather consider granting access to the repository at github.

Comment by Andy Clement [ 17/Feb/11 ]

The dev build that came out an hour or so ago includes the changes I mentioned above. This should get the transform to the point of executing. Dev update site here:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

Just browsing the code for the transform, what we might hit next is that you are using the typeclass for a ClassNode. Whilst compiling under eclipse we avoid using ClassNodes backed by real class entities (for coupling reasons). This means getTypeClass() can exit with an unusual error saying the caller is asking before it has been set (under eclipse it will never be set). Our ClassNodes can answer every question except getTypeClass (if they can't I'd take a bug on that).

I'm also in discussions with the groovyc team about removing getTypeClass() from ClassNode as it breaks the encapsulation (of ClassNode as a type abstraction). Anyway, let's see how far you get with the latest dev build. I could, for compatibility reasons, fill in a typeclass when it is requested, but also put out warnings about it - instead of hard failing.

Comment by Alexander Kitaev [ 18/Feb/11 ]

Hello Andy,

I've installed dev build and got the following exception on our sample project:

java.lang.NullPointerException
at java.lang.Class.isAssignableFrom(Native Method)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.verifyClassAndAddTransform(ASTTransformationCollectorCodeVisitor.java:242)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.addTransformsToClassNode(ASTTransformationCollectorCodeVisitor.java:237)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.visitAnnotations(ASTTransformationCollectorCodeVisitor.java:197)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:48)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.visitClass(ASTTransformationCollectorCodeVisitor.java:64)
at org.codehaus.groovy.transform.ASTTransformationVisitor$1.call(ASTTransformationVisitor.java:187)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1139)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:577)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:555)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:532)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:165)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1848)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:816)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:619)

Comment by Semyon Vadishev [ 18/Feb/11 ]

Andy,

ClassNode#getTypeClass() definitely causes the problems, at least sometimes it raises these scary error messages starting with "BUG!".

I've pushed a couple of changes to get rid of #getTypeClass() calls – I use ClassNode#getName() instead. Hopefully, returned String object always represents fully qualified class name – I couldn't find any documentation on that, though.

Comment by Andy Clement [ 18/Feb/11 ]

Are things behaving now then, if you take out the getTypeClass calls? THis morning I prototyped some code that would allow you to use them, even though I'm not a great fan of them, the typeclasses are faulted in using the same classloader that loaded the transform.

Comment by Andy Clement [ 18/Feb/11 ]

I've just committed the changes that will try and allow the use of typeclass (but it is better to avoid it if you can, I believe).

Comment by Semyon Vadishev [ 18/Feb/11 ]

With dev build
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

And commit replacing #getTypeClass() calls
https://github.com/vs/grooby/commit/22f210c25a33934f6d328eb266993c69c3f1f93c

We're still hitting NPE reported by Alex above. Compilation process seems to be aborted before our transformations started.

Regarding usages of #getTypeClass(), I agree that this method breaks encapsulation of ClassNode. But we have to access certain classes at compile time – not just to use Class object as a resolved binding, but also to get instance of the class and invoke necessary methods on it:

https://github.com/vs/grooby/blob/22f210c25a33934f6d328eb266993c69c3f1f93c/groovy-util/src/org/tmatesoft/grooby/exec/EsAstTransformationVisitor.groovy#L186

To get Class object specified as annotation member we do the following:

https://github.com/vs/grooby/blob/22f210c25a33934f6d328eb266993c69c3f1f93c/groovy-util/src/org/tmatesoft/grooby/exec/EsAstTransformationVisitor.groovy#L43

I have concern for that particular line – what ClassLoader is being used here? No doubt that groovyc (from command line, ant script or IntellIJ IDEA) handles that just fine. But is there any guarantee that compiled classes are available to the ClassLoader of Eclipse Groovy Builder/Plugin? I believe they have to be. Just because this is how the whole local AST transformation works, e.g. InsertMethodHash is annotated with transformation class which has to be loaded at compile time. But maybe there is another way to handle these things?

Comment by Andy Clement [ 19/Feb/11 ]

That NPE does look like something else I have to address before you can get called correctly.

> I have concern for that particular line – what ClassLoader is being used here? No doubt that groovyc (from command line, ant script or IntellIJ IDEA) handles that just fine.

A GroovyClassLoader is conjured up in eclipse and passed to groovyc for handling the ast transforms, the same process as is used in 'regular'/IntelliJ groovyc. This classloader has the classpath of the project.

> But is there any guarantee that compiled classes are available to the ClassLoader of Eclipse Groovy Builder/Plugin?

Yes, the classes for the transforms (and their dependencies) are available to the classloader that will be used to run the transforms, they do have to be. What you may not be able to see (and I haven't dug enough to see if this is what you are trying to do) is the compiled classes for the code that is in the process of being built. Whether the classloader can see those will depend on the compile ordering that happened to be chosen for this particular build

Comment by Andy Clement [ 19/Feb/11 ]

Hi. I've just cloned your repos and am trying to create that NPE from above:

java.lang.NullPointerException
at java.lang.Class.isAssignableFrom(Native Method)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.verifyClassAndAddTransform(ASTTransformationCollectorCodeVisitor.java:242)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.addTransformsToClassNode(ASTTransformationCollectorCodeVisitor.java:237)
at org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor.visitAnnotations(ASTTransformationCollectorCodeVisitor.java:197)

But it doesn't happen for me. Instead I see a pair of classloading problems (first concerning transformable, and then another one). I changed two places:

InsertMethodHashAstTransformation.loadClass

from
Class.forName(classNode.name)
to
Class.forName(classNode.name,false,this.getClass().getClassLoader())

and similarly in EsAstTransformationVisitor.fetchTransformationInfo

I then built the projects cleanly and ran the sample:

main: null
insertHash: eeda090b79f9130b7aced92aa928a558bac452d0
insertHashWithSkip: f26e7ac5cd9306f54c589b4ba856960f902f1dd6
insertHashWithNoSkip: f26e7ac5cd9306f54c589b4ba856960f902f1dd6
doNotInsertHash: null
wait: null
wait: null
wait: null
equals: null
toString: null
hashCode: null
getClass: null
notify: null
notifyAll: null

what am i doing differently to you that means I don't see the NPE? Should I be on a branch?

Comment by Semyon Vadishev [ 21/Feb/11 ]

Hello Andy, it's great to see that you've managed to run our code under Eclipse.

I've tried to investigate the reason of NPE on our side. It seems we came back to the issue of value:String[] and classes:Class[] members of GroovyASTTransformationClass. For annotation:

@GroovyASTTransformationClass(classes = [InsertMethodHashAstTransformation])
public @interface InsertMethodHash {

compiler somehow failed to find class InsertMethodHashAstTransformation, so object corresponding to the value of the member is null.

To workaround the issue I've modified that part a bit:

@GroovyASTTransformationClass(classes = [InsertMethodHashAstTransformation])
@GroovyASTTransformationClass("org.tmatesoft.grooby.cache.InsertMethodHashAstTransformation")

Unfortunately InsertMethodHashAstTransformation class is still unavailable for compiler. Here are the warnings we get from the builder:

Description Resource Path Location Type
Groovy:Could not find class for Transformation Processor org.tmatesoft.grooby.cache.InsertMethodHashAstTransformation declared by org.tmatesoft.grooby.cache.InsertMethodHash InsertHash.groovy /grooby/grooby/src/org/tmatesoft/grooby/example line 0 Java Problem
Groovy:Could not find class for Transformation Processor org.tmatesoft.grooby.exec.EsAstTransformation declared by org.tmatesoft.grooby.exec.ExecuteString StringCommand.groovy /grooby/grooby/src/org/tmatesoft/grooby/example line 0 Java Problem
Groovy:Could not find class for Transformation Processor org.tmatesoft.grooby.exec.EsAstTransformation declared by org.tmatesoft.grooby.exec.ExecuteString StringCommand.groovy /grooby/grooby/src/org/tmatesoft/grooby/example line 0 Java Problem

At the same time builder output directory contains InsertMethodHashAstTransformation.class file. Most probably ClassLoader causes the problem, what do you think?

what am i doing differently to you that means I don't see the NPE? Should I be on a branch?

We use 'master' branch of the github repository. Please, ensure you have no locally modified files. Most probably the actual difference is in environment – JDT/Groovy/Groovy plugin version? I'm no expert in that.

Comment by Andy Clement [ 21/Feb/11 ]

Just want to check a couple of things. I have just sync'd up with master and it all works fine for me. The important level of groovy-eclipse I happen to have installed is the latest dev build: 2.1.2.xx-20110218-1500-e36

All I have done is clone your projects, define them in eclipse and finally add a project dependency from grooby onto groovy-util. Have you setup that final project dependency?

Comment by Alexander Kitaev [ 21/Feb/11 ]

Hello, Andy!

You're right, I had a single "grooby" project with three source roots defined - one for grooby/src and others for groovy-util/src and groovy-util/test. Looks like there is no way in Eclipse to define dependency between source roots, it only could be done on a project level. So, I've created two separate projects with a dependency, and problem was resolved just as you said.

Respect, bro and many thanks for your help!

In our production project I've added another project (groovy-util) so that it compiles before groovy code that uses transformations defined there. Looks not very nice (.project file inside another project), but works!

Comment by Semyon Vadishev [ 21/Feb/11 ]

Thanks a lot from me, too!

Comment by Andy Clement [ 21/Feb/11 ]

Glad you have it working. One last thing... To help transform developers I've added some timers. If you have the 'console' view open in eclipse - in the bottom right click the pulldown and choose groovy event console. In that you will see events relating to AST transforms. You will see:

Ast Transforms : 10:13:01 Classpath for GroovyClassLoader (used to discover transforms): XXXXXXXXXX

which will show the classpath of the classloader being used to resolve ast transforms and their dependencies.

Ast Transforms : 10:14:00 Global transform groovy.grape.GrabAnnotationTransformation on /grooby/src/org/tmatesoft/grooby/example/StringCommand.groovy = 0ms
Ast Transforms : 10:14:00 Global transform org.codehaus.groovy.ast.builder.AstBuilderTransformation on /grooby/src/org/tmatesoft/grooby/example/StringCommand.groovy = 0ms

Ast Transforms : 10:14:01 local transform org.tmatesoft.grooby.exec.EsAstTransformation on org.tmatesoft.grooby.example.StringCommand:org.tmatesoft.grooby.example.StringCommand = 318ms
Ast Transforms : 10:14:01 local transform org.tmatesoft.grooby.exec.EsAstTransformation on org.tmatesoft.grooby.example.StringCommand:MethodNode@1677624934[void main([Ljava.lang.String;)] = 6ms

Here you see it also shows you time spent in Ast transforms for particular nodes. The 318ms there is just because I was running it for the first time (so classloading time). Next few times (each event comes out when I save):

Ast Transforms : 10:14:54 local transform org.tmatesoft.grooby.exec.EsAstTransformation on org.tmatesoft.grooby.example.StringCommand:org.tmatesoft.grooby.example.StringCommand = 1ms

Ast Transforms : 10:14:56 local transform org.tmatesoft.grooby.exec.EsAstTransformation on org.tmatesoft.grooby.example.StringCommand:org.tmatesoft.grooby.example.StringCommand = 1ms

Maybe you'll find that useful, it will be in a dev build today. Oh, one thing I should say - logging all that stuff isn't free so having the event console active will slightly impact performance, always close it for max performance.





[GRECLIPSE-986] Backslash u in a comment produces a weird parser error Created: 07/Feb/11  Updated: 14/Oct/11  Resolved: 07/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Parser
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Patrick Jayet Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.6.1, Windows XP


Number of attachments : 0

 Description   

If we include backslash u as comment in a script (without being a correct unicode escape sequence), we get no compiler error, just a warning at the top of the class/script with the stacktrace [1]. The class/script is not properly compiled and cannot be referenced from other classes/scripts. The error is very difficult to diagnose, since we have no precise location of the problem in the script and even no precise problem description from the compiler.

The example of such a script is the following:

// hello \u
class Foo{}

Note 1: this problem is particularly tacky, since '\u' sequences can occur 'naturally' as part of pasting windows paths within comments

Note 2: java does not allow an incomplete unicode escape sequence either, but mark such an occurence with a compile time error, the problematic location underlined in red and the error message 'Invalid unicode'. I would expect the Groovy editor to do the same.

[1] Stacktrace shown as warning at the top of the class

antlr.TokenStreamIOException: Did not find four digit hex character code. line: 3 col:9
at org.codehaus.groovy.internal.antlr.parser.GroovyLexer.nextToken(GroovyLexer.java:710)
at org.codehaus.groovy.internal.antlr.parser.GroovyLexer$1.nextToken(GroovyLexer.java:249)
at antlr.TokenBuffer.fill(TokenBuffer.java:69)
at antlr.TokenBuffer.LA(TokenBuffer.java:80)
at antlr.LLkParser.LA(LLkParser.java:52)
at org.codehaus.groovy.internal.antlr.parser.GroovyRecognizer.identifier(GroovyRecognizer.java:1740)
at org.codehaus.groovy.internal.antlr.parser.GroovyRecognizer.packageDefinition(GroovyRecognizer.java:941)
at org.codehaus.groovy.internal.antlr.parser.GroovyRecognizer.compilationUnit(GroovyRecognizer.java:686)
at org.codehaus.groovy.antlr.ErrorRecoveredCSTParserPlugin.transformCSTIntoAST(ErrorRecoveredCSTParserPlugin.java:62)
at org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:79)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:260)
at org.codehaus.groovy.control.CompilationUnit$8.call(CompilationUnit.java:179)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:943)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:574)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:550)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:527)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:165)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.dietParse(GroovyParser.java:309)
at org.codehaus.jdt.groovy.integration.internal.MultiplexingCommentRecorderParser.dietParse(MultiplexingCommentRecorderParser.java:60)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:159)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUnit(SourceTypeConverter.java:121)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:698)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:613)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyBuilder.buildSupertypes(HierarchyBuilder.java:125)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:135)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:300)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1263)
at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:726)
at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:678)
at org.eclipse.jdt.internal.junit.util.CoreTestSearchEngine.isTestImplementor(CoreTestSearchEngine.java:115)
at org.eclipse.jdt.internal.junit.launcher.JUnit3TestFinder.isTestImplementor(JUnit3TestFinder.java:91)
at org.eclipse.jdt.internal.junit.launcher.JUnit3TestFinder.isTest(JUnit3TestFinder.java:87)
at org.eclipse.jdt.internal.junit.util.CoreTestSearchEngine.isTestOrTestSuite(CoreTestSearchEngine.java:54)
at org.eclipse.jdt.internal.junit.JUnitPropertyTester.isJUnitTest(JUnitPropertyTester.java:113)
at org.eclipse.jdt.internal.junit.JUnitPropertyTester.canLaunchAsJUnitTest(JUnitPropertyTester.java:88)
at org.eclipse.jdt.internal.junit.JUnitPropertyTester.test(JUnitPropertyTester.java:71)
at org.eclipse.core.internal.expressions.Property.test(Property.java:58)
at org.eclipse.core.internal.expressions.TestExpression.evaluate(TestExpression.java:99)
at org.eclipse.core.internal.expressions.CompositeExpression.evaluateAnd(CompositeExpression.java:53)
at org.eclipse.core.internal.expressions.AdaptExpression.evaluate(AdaptExpression.java:91)
at org.eclipse.core.internal.expressions.CompositeExpression.evaluateAnd(CompositeExpression.java:53)
at org.eclipse.core.internal.expressions.IterateExpression.evaluate(IterateExpression.java:150)
at org.eclipse.core.internal.expressions.CompositeExpression.evaluateAnd(CompositeExpression.java:53)
at org.eclipse.core.internal.expressions.WithExpression.evaluate(WithExpression.java:72)
at org.eclipse.core.internal.expressions.CompositeExpression.evaluateAnd(CompositeExpression.java:53)
at org.eclipse.core.internal.expressions.EnablementExpression.evaluate(EnablementExpression.java:53)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchShortcutExtension.evalEnablementExpression(LaunchShortcutExtension.java:287)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationManager.getApplicableConfigurationTypes(LaunchConfigurationManager
.java:744)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationManager.getApplicableLaunchConfigurations(LaunchConfigurationManag
er.java:780)
at org.eclipse.debug.internal.ui.contextlaunching.LaunchingResourceManager.getParticipatingLaunchConfigurations(LaunchingResourceManager.ja
va:506)
at org.eclipse.debug.internal.ui.contextlaunching.LaunchingResourceManager.getLabel(LaunchingResourceManager.java:320)
at org.eclipse.debug.internal.ui.contextlaunching.LaunchingResourceManager.computeLabels(LaunchingResourceManager.java:241)
at org.eclipse.debug.internal.ui.contextlaunching.LaunchingResourceManager$2.run(LaunchingResourceManager.java:138)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)



 Comments   
Comment by Andy Clement [ 07/Feb/11 ]

related: (closed as wont fix) http://jira.codehaus.org/browse/GROOVY-1679

Comment by Andy Clement [ 07/Feb/11 ]

Ok, I don't want to get into messing around with the grammar.
I've put in a change that will record this error against the correct location, unfortunately as the lexer exits immediately via an exception when it occurs, groovy will not process anything else in the file. This means you must address what it is complaining about in order for the parsing of the rest of the file to succeed. Given that the construct will break groovyc anyway, it isn't like you'd want to leave these in your program anyway.

Comment by Patrick Jayet [ 07/Feb/11 ]

Hi Andy,

That's more than enough. The indication of the precise location (and possibly a more or less precise error message) is all that we need. As you say, this problem in the code needs to be addressed anyway.

Good job. Thx.





[GRECLIPSE-984] Extract method fails with error message "More then 1 return values are found in selection. Update your selection." when refactoring should be possible Created: 01/Feb/11  Updated: 08/Feb/11  Resolved: 08/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Critical
Reporter: Lari Hotari Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Greclipse 2.1.1.xx-20101215-2100-e36 ; STS 2.5.2.RELEASE (Build Id: 201101081000)


Number of attachments : 0

 Description   

Extracting a method from lines that modifies a Map doesn't work if the same Map is modified (a property is set to some object reference) in the lines after the selection.

I have this type of code in a Grails controller:

1	private void test(a, b) {
2		if(!a.someprop) {
3			a.someprop = 'x'
4			a.someprop2 = 'y'
5		}
6		a.otherprop = b.otherprop
7	}

When I select lines 3 & 4 and choose "Refactor->Extract Method", I get a error message:
"More then 1 return values are found in selection. Update your selection.

Found return values:
Object b
Object a
"

However if I remove the line 6 (a.otherprop = b.otherprop), I'm able to extract the method from lines 3 & 4.

There is no problem extracting a method in this case:

1	private void test(a, b) {
2		if(!a.someprop) {
3			a.someprop = 'x'
4			a.someprop2 = 'y'
5		}
7	}

I hope this example helps fixing this annoying bug.

Here is another example where refactoring doesn't work (select lines 4 & 5 and do "Refactor->Extract Method"):

1	private void test(a) {
2		def c='z'
3		if(!a.someprop) {
4			a.someprop = 'x'
5			a.someprop2 = 'y'
6		}
7		a.otherprop = c
8	}

If line 7 is removed, refactoring works.



 Comments   
Comment by Lari Hotari [ 01/Feb/11 ]

Extracting methods fails also for code using DSLs (handling propertyMissing).

Example code from a Grails Controller:

1	def list = {
2		def resultList = SomeDomainClass.list()
3		def resultCount = resultList.size()
4		
5		render(contentType:"text/json") {
6			success = true
7			results = resultCount
8			rows = resultList
9		}
10	}

Let's say I'd like to extract a method for the render call (lines 5-9). This isn't possible. It fails complaining that success, results and rows are return values.

I'd like to have the refactoring feature ignore return value checking or at least have a possiblity to "force" refactoring.

Comment by Andrew Eisenberg [ 01/Feb/11 ]

Thanks for reporting. I'll have a look.

Comment by Andrew Eisenberg [ 01/Feb/11 ]

What's happening here is that the control flow analysis is slightly incorrect. It is thinking that any variables that are used after the code block extracted should be considered return values.

However, the correct analysis should be that the return parameters are the intersection between the variables that are used after the extracted block and the variables assigned inside of it.

Comment by Andrew Eisenberg [ 05/Feb/11 ]

Fixed with regression tests.

Comment by Andrew Eisenberg [ 07/Feb/11 ]

Reopening since there are a few failing tests due to this change. I need to explore deeper what's happening.

Comment by Andrew Eisenberg [ 08/Feb/11 ]

Fixed now.





[GRECLIPSE-983] Inner classes created in Groovy cause compile errors when referenced from Java Created: 27/Jan/11  Updated: 24/Nov/11  Resolved: 16/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: Travis Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Inner classes compiled in groovy cause compile errors in java in eclipse. The errors go away when doing a full project clean but come right back as soon as the java file that is referencing the inner class is changed (rebuilt). This basically makes it impossible to use inner classes in joint java/groovy projects

See the following example:

//groovy code
class Outer {
  static class Inner {}
}
//java code
public class Client {
  { new Outer.Inner(); }
}

As I said if I do a project clean everything compiles. As soon as I edit and save Client.java eclipse gives me the following error:

Outer.Inner cannot be resolved to a type	Client.java	/GroovyTest/src/main/java	line 3	Java Problem


 Comments   
Comment by Travis [ 27/Jan/11 ]

IntelliJ IDEA has the same problem. See http://youtrack.jetbrains.net/issue/IDEA-50708

Comment by Travis [ 28/Jan/11 ]

I open the following jira with the groovy project:

http://jira.codehaus.org/browse/GROOVY-4649

Comment by blackdrag blackdrag [ 17/Feb/11 ]

the related issue GROOVY-4649 is now closed

Comment by Andy Clement [ 17/Feb/11 ]

we'll pick up the fix when we move to 1.7.9

Comment by Andrew Eisenberg [ 10/Jun/11 ]

I was hoping that this was fixed after the upgrade to 1.7.10. But, this is only kind of working now from inside Eclipse. When I use the code above exactly, I get this compile problem:

The constructor Outer.Inner() is undefined	Client.java	/GroovyTest/src/foo	line 4	Java Problem

The problem goes away when I add an explicit constructor to the inner class:

class Outer {
  static class Inner {
    Inner() {}
  }
}

I get the same behavior for both 1.7.10 and 1.8.0.

However, when I compile the original code from the command line, there are no compile errors (I was using 1.8.0 from the command line).

I will lower the priority here since this is partially fixed.

Comment by Travis [ 10/Jun/11 ]

Well there is another issue I noticed the other day with Groovy 1.8 and static inner classes.

When you have multiple static inner classes you get compile errors. If I recall the error is something to do with duplicate classes or something... I'll try to do some more testing on my end when I get a chance. This might be something to test on your end if your working on this....

The case is something like:


class Outer {
  static class Inner1 { }
  static class Inner2 { }
}

Comment by Andrew Eisenberg [ 29/Sep/11 ]

Still a problem, or at least the original comment is still a problem.

Travis, have you been able to narrow down the problem described in your comment? I have not been able to reproduce.

Comment by Travis [ 29/Sep/11 ]

I have not had a chance to give this a test. Most of our team has switched to using Intellij so I haven't heard any complaints of this lately... We do plan on using the eclipse compiler via maven at that point so this could affect us then.

The original issue had to do with the core groovy compiler not compiling static inner classes correctly. Now it seems that is fixed but maybe there is a problem with multiple static inner classes. Could this be a problem in the core groovy compiler too? I'm not sure how greclipse uses the groovy compiler....

Comment by Andy Clement [ 16/Oct/11 ]

The "The constructor Outer.Inner() is undefined" is also a groovy 'bug'. I just raised http://jira.codehaus.org/browse/GROOVY-5080 - groovy incorrectly tags the generated constructor as synthetic.

You won't see it on the command line if you compile the java and groovy together in one step, you need to do a two part compile, the groovy and then java. That more closely mirrors the eclipse incremental build that shows the problem. An eclipse full build won't show the problem.

As for this:

class Outer {
  static class Inner1 { }
  static class Inner2 { }
}

Can't get it to fail for me, maybe we've picked up some fix in 1.8.3 that addressed something in this area. please open a new bug if you see something in this area.

Oh, and I've committed the fix for the groovy bug 5080 into our copy of groovyc, so that under greclipse we won't tag the constructors incorrectly.

Comment by Peter Butler [ 23/Nov/11 ]

This fails for me with the following code (all code in .groovy files):

 
package com.company.somepackage
public interface SomeInterface {
    SomeGroovyObject doSomething(SomeOtherGroovyObject param)
}

package com.company.somepackage
class SomeTestClass {
    void setup() {
        testObject.someProperty = new SomeInterface() {
            return new SomeGroovyObject()
        }
    }
}

The compiler gives an error like:

 
SomeTestClass.groovy (at line 1)
	package com.company.somepackage
	^
The type com.company.somepackage.SomeInterface$1 cannot be resolved. It is indirectly referenced from required .class files

I've tried this from Maven on both 2.5.2-01 and 2.6.0-SNAPSHOT of groovy-eclipse-compiler. I've also checked out groovy-eclipse-compiler from svn and built but it fails with the same error.

Comment by Andy Clement [ 24/Nov/11 ]

Hi Peter,

Can you maybe give me a complete failing project that shows this problem? The code above is missing SomeOtherGroovyObject and SomeGroovyObject - but even when I supply stub implementations of them, the setup() method shows a problem:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
SomeTestClass.groovy: 13: unexpected token: return @ line 13, column 5.
   				return new SomeGroovyObject()

I dont get as far as a resolution error.





[GRECLIPSE-982] grails->refresh dependencies terminates without warning if compilation takes longer than 15 seconds Created: 27/Jan/11  Updated: 16/Mar/11  Resolved: 28/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.0Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: kris helenek Assignee: Andy Clement
Resolution: Won't Fix  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It looks like the grails->refresh dependencies action launches a grails script, and then gives it 15000 milliseconds to complete. If the script takes longer than that, it kills the script silently. I don't think the timeout needs to be there at all, since the user has the ability to terminate the process, and there is visual feedback of the progress of the script from the script's output. If it cannot be removed, it should be longer or configurable. At the very least alert the user that the script did not run.



 Comments   
Comment by Andy Clement [ 27/Jan/11 ]

Issues against the Grails tools should be raised against STS:
https://issuetracker.springsource.com/browse/STS

assigning to Kris

Comment by Andy Clement [ 28/Jan/11 ]

The default timeout is configurable. In the preferences go to Groovy>Grails>Grails Launch, at the bottom the default is 15000ms.

Comment by Andy Clement [ 28/Jan/11 ]

I've raised this issue (https://issuetracker.springsource.com/browse/STS-1524) in STS to cover getting a better dialog and describe to the user where the timeout value can be set.

Comment by Andy Clement [ 28/Jan/11 ]

nothing to fix in groovy-eclipse, any work will be done under the referenced STS issue.





[GRECLIPSE-981] compilation errors Created: 25/Jan/11  Updated: 16/Mar/11  Resolved: 25/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Matthias Pfau Assignee: Andy Clement
Resolution: Duplicate  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Number of attachments : 0

 Description   

It is not possible to build gradle (https://github.com/gradle/gradle) with the current release of the eclipse plugin.

The compilation errors occurs probably because the imports are applied by the eclipse plugin in another order compared to the groovy compiler.

The critical parts of the code seem to be:

import org.gradle.api.*
import org.gradle.api.internal.*
[...]
Factory<AntBuilder> antBuilderFactoryMock
AntBuilder testAntBuilder

The compiler reports the following errors:

  • The type AntBuilder is ambiguous
  • The type Factory is ambiguous

The specified imports seem to overlap with groovy.util.Factory and groovy.util.AntBuilder

How to reproduce:

git clone https://github.com/gradle/gradle.git
cd gradle
gradle eclipse

Import the Project into eclipse and open the type org.gradle.api.internal.project.DefaultProjectTest.



 Comments   
Comment by Andy Clement [ 25/Jan/11 ]

This is a dup of http://jira.codehaus.org/browse/GRECLIPSE-945 - I've done some work on it, but it is complicated to address.





[GRECLIPSE-979] Simply assign the Groovy Editor if the file ends in .gradle Created: 25/Jan/11  Updated: 18/Mar/11  Resolved: 18/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.5.0Release

Type: Improvement Priority: Minor
Reporter: Bruce Petro Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

All


Number of attachments : 0

 Description   

If I drag a gradle script into the eclipse editor box, it doesn't default to the groovy editor. Change has been made, but not yet committed.



 Comments   
Comment by Bruce Petro [ 25/Jan/11 ]

Sorry - didn't intend this to come up as Major Priority... and I don't see how I can change it - sorry!

Comment by Bruce Petro [ 25/Jan/11 ]

PS: I haven't done it yet, but I'm sure there is a way to change Eclipse setup and assign the groovy editor for .gradle extensions - my suggestion is simply that you ought to do that (and any other obvious groovy files) during the install process. THANKS for all your work!

Comment by Andrew Eisenberg [ 25/Jan/11 ]

Yes, there is a way to set *.gradle to use the groovy editor as the default. Go to Preferences -> General -> Editors -> File associations and add *.gradle with a groovy editor as a default.

However, this will only associate the file with the editor. it will not send it to the Java/Groovy builder. This may be the desired behavior since there is no support for gradle built into Groovy-Eclipse (there is a gradle plugin for Eclipse that is produced by the gradle team, however).

If you do want to try sending your gradle files to the compiler (which will have the side effect of making searchable and navigable and giving them some bit of content assist), you can go to Preferences -> General -> Content Types -> Text -> Java -> Groovy Source and add *.gradle there.

You will also probably want to mark your gradle files as "Groovy scripts". You can do this in Preferences -> Groovy -> Compiler.

We should consider making this the default, but as you can see, there are several things we need to think about.

Comment by Andrew Eisenberg [ 21/Feb/11 ]

Kris, I think this functionality should be included in the STS support for gradle and not in Groovy-Eclipse. So, this is really an STS issue.

Comment by Andrew Eisenberg [ 18/Mar/11 ]

In the end, I think it makes sense to support gradle files in Groovy-Eclipse. Since all gradle files are groovy files even if there is no explicit gradle support.





[GRECLIPSE-978] Installing 2.1.1 plugin alters default java hover behavior Created: 25/Jan/11  Updated: 30/Jan/11  Resolved: 30/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Mike Kilgore Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS X 10.6, Eclipse 3.6


Number of attachments : 0

 Description   

After installation of the 2.1.1 plugin the normal hover behavior in Eclipse Debug mode (java application) to display active variable does not work. It appears that including the 'Groovy Information Hover' into the eclipse java editor hover causes this change. Was this change expected? An alternative would be to provide a Groovy editor specific hover option...



 Comments   
Comment by Andrew Eisenberg [ 25/Jan/11 ]

I have a solution for this locally, but won't commit it into the dev build until the M1 build of STS 2.6.0 is complete.

Comment by Andrew Eisenberg [ 30/Jan/11 ]

Committed the fix. It will be available in the next dev build.





[GRECLIPSE-977] Internal Compiler error on GPars project Created: 24/Jan/11  Updated: 17/Aug/11  Resolved: 17/Aug/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Blocker
Reporter: Russel Winder Assignee: Andy Clement
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Maverick / Debian Testing ; Eclipse Helios ; GrEclipse snapshot 2011-01-24


Number of attachments : 0

 Description   

Trying to compile the GPars project In Eclipse/GrEclipse leads to:

Internal compiler error: java.lang.NoClassDefFoundError: groovyx/gpars/activeobject/InternalActor at groovyx.gpars.activeobject.ActiveObjectASTTransformation
$MyClassCodeExpressionTransformer.addActorFieldToClass(ActiveObjectASTTransformation.java:201)

The code compiles fine (and all the tests pass using the Gradle build or IntelliJ IDEA.



 Comments   
Comment by Andy Clement [ 24/Jan/11 ]

Just checking that you are expecting gpars to all compile cleanly on groovy 1.7.5 - the current version included in groovy-eclipse.

Comment by Andy Clement [ 24/Jan/11 ]

I just grabbed:

git clone git://git.codehaus.org/gpars.git GPars

That refers to groovy 1.6.9 - is that what you are expecting to use in groovy eclipse? I can't remember the last update I did for the 1.6 compiler level, let me check ... looks like 1.6.7

Comment by Russel Winder [ 24/Jan/11 ]

GPars should work with 1.7.5. I have now though upgraded to using 1.7.6 in the central master.

I have given up using 1.6.9, it shouldn't now be mentioned anywhere associated with GPars. The .classpath file in the Git repository says 1.7.6, where are you getting 1.6.9 from?

Comment by Russel Winder [ 24/Jan/11 ]

Ah, should have said the Gradle build uses 1.6.9 still but the Eclipse and IntelliJ IDEA builds should be using 1.7.6. I don't use Gradle from Eclipse of IntelliJ IDEA, I use the native builds.

Comment by Andy Clement [ 24/Jan/11 ]

ok, I see what this is. Groovy-Eclipse tries to work around a limitation that Eclipse has. Eclipse does not consider src and test folders as separate - everything is compiled together. This means you cannot, in your test code, assume everything in the src folder has been built and is ready for use. This is not normally an issue for a standard project but when you throw AST transforms into the mix, you can come unstuck. Per the groovy-eclipse FAQ:

http://groovy.codehaus.org/Eclipse+Plugin+2.0.0+FAQ#EclipsePlugin2.0.0FAQ-Q.DoesitsupportcustomASTtransformations%3F

you can only compile/use ast transforms in the same groovy-eclipse project if they are pure java with pure java dependencies. In your case the java ActiveObjectASTTransformation type has a dependency on the InternalActor type which is a groovy type.

Groovy-Eclipse tries to help by ensuring java code is compiled ahead of groovy code - this is what enables us to consume ast transforms written in pure java with pure java dependencies.

Resolving this properly really needs Eclipse support for separate src/test folders.

What we could do for now is at least make this mode of operation optional - since it can leave you in a messy state with cryptic errors. I've manually turned off support for ast transforms (consuming them in the project where they are defined) and then I see proper errors related to attempts to use the ast transform from the testcases - those kinds of error are definetly better than a crash/error log entry.

Comment by Andy Clement [ 27/Jan/11 ]

I've committed a change so that if a transformation breaks the current rules like this, it doesn't crash the entire compilation process. You'll now get a suitable error against the type attempting to use the transform and a (unfortunately unfriendly) link to the FAQ about it.

Comment by Andrew Eisenberg [ 21/Feb/11 ]

Are we planning on a complete fix for this issue? Seems to me that this would be extremely difficult given Eclipse's source folder limitations. If not, would there be any more work to do for this bug?

Comment by Andrew Eisenberg [ 17/Aug/11 ]

I am resolving issue since we are not planning on putting any more effort into getting around Eclipse's source folder limitation. There is not much more we can do here.

At this point, it is up to the AST transform creators to create their transforms in a way that is amenable to the JDT compiler.





[GRECLIPSE-976] Ability to set method entry breakpoints in Groovy code Created: 21/Jan/11  Updated: 21/Jan/11  Resolved: 21/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Improvement Priority: Major
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to GRECLIPSE-967 Breakpoint is set on wrong line numbe... Resolved
Number of attachments : 0

 Description   

Since I'm working in this code anyway, it seems possible to provide the ability to set method entry breakpoints.



 Comments   
Comment by Andrew Eisenberg [ 21/Jan/11 ]

Working now. Will commit along with fix for GRECLIPSE-967.





[GRECLIPSE-975] not friendly to create Groovlet/GSP under a dynamic website project in Eclipse Created: 21/Jan/11  Updated: 22/Nov/13  Resolved: 22/Jun/11

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.1.1Release
Fix Version/s: 2.5.1Release

Type: Improvement Priority: Minor
Reporter: LiQun Li Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse 3.6.1
Groovy Eclipse plugin 2.1.1
Java 1.6.0_23


Number of attachments : 0

 Description   

Under a dynamic website project in Eclipse, it is unable/ not friendly to create Groovlets/GSPs. When right click the name of a dynamic website project, JSP/Servlet can be found and created from New->Wizard->Web. Even though a groovy class can created too, users have to care about other details. Hope Groovlet/GSP creation would be as easy as Servlet/JSP's, or try to mitigate some effort.



 Comments   
Comment by Andrew Eisenberg [ 04/Mar/11 ]

Can you be a little more specific about what you require here? What is the exact behavior that you would like to see?

Also, this is probably an STS issue since the GSP wizard is part of STS, not Groovy-Eclipse.

Comment by Andrew Eisenberg [ 22/Jun/11 ]

No extra information from the user. Closing this bug. Please re-open if you want to describe in more detail what you are looking for.

Comment by Guy Rouillier [ 29/Dec/12 ]

I just found this issue by searching. I'm trying to create my first groovlet in Eclipse, using Groovy 2.0.6. As lee said on the mailing list http://groovy.329449.n5.nabble.com/How-to-create-a-groovlet-in-Eclipse-td3351347.html, I'd say start simple.

I'd like to be able to create a web project in Eclipse with a Groovy nature. Minimum requirements would be that (1) Eclipse recognizes the project as a web project, with a WEB-INF folder, web.xml and JARs in WEB-INF/lib; and (2) Groovy recognizes the .groovy files and provides it's normal assistance. I understand that the Groovy plugin currently doesn't recognize the groovlet DSL; would be better if it did, but can live without that as a first step. If the plugin can be updated to still provide assistance on the script parts but ignore the HTML parts, that a good start.

[UPDATE] Many hours later...

I've made some progress. I started by creating a dynamic web project. Once the web project was created, I was then able to right click on the project name and a menu item showed allowing me to "change to Groovy project". Fortunately, that action kept all the web project artifacts: webroot, etc. Because this was intended to be a quick and dirty project, I originally put a .groovy script under WebRoot, containing all my logic as well as the HTML. (I gave up on MarkupBuilder and resorted to inline HTML; I was having to convert HTML tags in my head anyway, so I decided why bother.) That didn't work very well; context assist is essentially non-functional. That approach is parallel to JSP model 1, which is strongly discouraged anyway.

So, I then moved all the logic into a Groovy class under the src directory. The groovlet now contains just the fragments need to retrieve and set parameters for the page display, as well as the HTML. Context assist works great for files in the src directory. So that is all good, and I can iterate development very easily with the built-in Tomcat 7.

But it is far from perfect. Since Eclipse doesn't know about groovlets, it doesn't copy all the required libs into the WEB-INF/lib directory. I had to do that manually. That's where enhancements to the Groovy plug-in would help groovlets. When I'm all done, I'll do all that in build.xml and ivy.xml.

Comment by Jochen Eddelbuettel [ 22/Nov/13 ]

Hi Andy,
I'd like to see this happening as well. It would be cool if Groovy-Eclipse could introduce a file type for Groovelets, resulting in *.groovy files that reside anywhere in the WebContent branch of a dynamic web project with Groove enabled. The creation wizard should not ask for a package and a location in the src branch. Optionally, when adding a Groovlet it might also check whether the GroovyServlet is present in web.xml and offer to add it. Forget about the GSP part of the request. That is indeed Grails stuff.
Cheers, Jochen





[GRECLIPSE-974] static import of enum that is defined as a property inside a class gives exception when used in constructor and static method Created: 21/Jan/11  Updated: 21/Jan/11  Resolved: 21/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Timothy Freyne Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OSX


Attachments: Zip Archive TestGroovy.zip    
Number of attachments : 1

 Description   

When creating an enum inside a class and try to use this enum in a constructor or a static method of another class this only works if you fully qualify name of the enum. It fails when you use a static import and displays this error: "Groovy:Apparent variable '[actual enum name]' was found in a static scope but doesn't refer to a local variable, static field or class. Possible causes:"

See attached zip for a simple Eclipse project with 3 classes that demonstrates this issue



 Comments   
Comment by Timothy Freyne [ 21/Jan/11 ]

Simple Eclipse Project with 3 classes that demonstrates the issue

Comment by Andy Clement [ 21/Jan/11 ]

Thanks for the testcase, it really helps.

Our handling for enum fields wasn't great - I've fixed it up which addresses your test scenario and improves navigation so that when you click on one you actually go to the right place now, rather than just to the file containing the declaration.

The problem was that groovy and JDT think about these things in different ways. In JDT an enum field is identifiable as having no modifiers set and a null type. In Groovy it has the type of the defining class and modifiers are set (including the AccEnum bit). We were not correctly creating JDT enum field declarations - and this meant JDT failed to convert them into field bindings. If they aren't bindings then the lookup for them will fail (and you will get problems as shown in the error message for the testcase included here). Creating them correctly makes JDT happy, bindings are created and the testcase works. Fix will be in a dev build shortly.





[GRECLIPSE-972] NPE seen in error log Created: 20/Jan/11  Updated: 21/Jan/11  Resolved: 21/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.0Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
java.lang.NullPointerException
	at org.codehaus.groovy.ast.ClassNode.getProperty(ClassNode.java:608)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTClassNode.getProperty(JDTClassNode.java:528)
	at org.eclipse.jdt.groovy.search.SimpleTypeLookup.findPropertyInClass(SimpleTypeLookup.java:618)
	at org.eclipse.jdt.groovy.search.SimpleTypeLookup.findDeclaration(SimpleTypeLookup.java:538)
	at org.eclipse.jdt.groovy.search.SimpleTypeLookup.findTypeForNameWithKnownObjectExpression(SimpleTypeLookup.java:384)
	at org.eclipse.jdt.groovy.search.SimpleTypeLookup.findType(SimpleTypeLookup.java:196)
	at org.eclipse.jdt.groovy.search.SimpleTypeLookup.lookupType(SimpleTypeLookup.java:89)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.handleExpression(TypeInferencingVisitorWithRequestor.java:696)
	at org.eclipse.jdt.groovy.search.TypeInferencingVisitorWithRequestor.visitConstantExpression(TypeInferencingVisitorWithRequestor.java:1080)


 Comments   
Comment by Andy Clement [ 20/Jan/11 ]

At line 608 either the property is null or the name of the property is null.

Comment by Andy Clement [ 21/Jan/11 ]

synchronized the intialization of property data. Andrew rightly pointed out two threads could be interfering with each other in that code. hard to 100% confirm the fix when we can't recreate this easily. I've added extra debug that will pop up in the log if this happens again.





[GRECLIPSE-970] @Immutable transformations that have a dependency require manual project clean to compile Created: 20/Jan/11  Updated: 23/Jul/14  Resolved: 23/Jul/14

Status: Closed
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.9.1.Release

Type: Bug Priority: Major
Reporter: Johannes Link Assignee: Unassigned
Resolution: Fixed  
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

osx, eclipse Helios Release, Groovy-Eclipse Feature 2.1.2.xx-20110117-1900-e36, groovy-all-1.7.5.jar and groovy-1.7.5.jar replaced by 1.7.6 versions


Number of attachments : 0

 Description   

If two @Immutable classes depend on each other, every file change in one of these classes requires a manual "Pproject>>Clean>>MyProject". I had to replace the groovy jars in the plugin dir since nested immutables are broken in groovy 1.7.5. I guess the problem might occur with other AST dependencies as well.

Example:

File "MyImmutable":

@Immutable
class MyImmutable

{ int val }

File "OtherImmutable":

@Immutable
class OtherImmutable

{ MyImmutable my }

 Comments   
Comment by Johannes Link [ 20/Jan/11 ]

Additional information: It works fine if both classes are in the same file, though.

Comment by Andrew Eisenberg [ 17/Aug/11 ]

This is still a problem on Groovy 1.8. However, I also see an NPE coming in on line org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(BlockStatement).

Comment by Denis Murashev [ 10/Jul/14 ]

Looks like already fixed (at least in version 2.9.0.RELEASE).

Comment by Denis Murashev [ 23/Jul/14 ]

Looks like it was already fixed





[GRECLIPSE-969] NPE when opening Java perspective in STS-2.5.2 Created: 20/Jan/11  Updated: 20/Jan/11  Resolved: 20/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Joris Kuipers Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.5.2 with Groovy Eclipse plugin installed through Extensions tab (2.1.1.xx-20101215-2100-e36)

eclipse.buildId=2.5.2.201101081000-RELEASE
java.version=1.6.0_21
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=nl_NL
Framework arguments: -product com.springsource.sts.ide -showLocation
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product com.springsource.sts.ide -showLocation


Number of attachments : 0

 Description   

With a newly created workspace I closed the Spring perspective and opened the Java perspective. This gave me the following NPE:

java.lang.NullPointerException
at org.codehaus.groovy.eclipse.GroovyPlugin$JUnitPageListener.pageOpened(GroovyPlugin.java:50)
at org.eclipse.ui.internal.PageListenerList$3.run(PageListenerList.java:98)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.runtime.Platform.run(Platform.java:888)
at org.eclipse.ui.internal.PageListenerList.fireEvent(PageListenerList.java:53)
at org.eclipse.ui.internal.PageListenerList.firePageOpened(PageListenerList.java:96)
at org.eclipse.ui.internal.WorkbenchWindow.firePageOpened(WorkbenchWindow.java:1410)
at org.eclipse.ui.internal.WorkbenchWindow.busyOpenPage(WorkbenchWindow.java:770)
at org.eclipse.ui.internal.WorkbenchWindow$9.run(WorkbenchWindow.java:1824)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.openPage(WorkbenchWindow.java:1821)
at org.eclipse.ui.handlers.ShowPerspectiveHandler.openPerspective(ShowPerspectiveHandler.java:150)
at org.eclipse.ui.handlers.ShowPerspectiveHandler.openOther(ShowPerspectiveHandler.java:118)
at org.eclipse.ui.handlers.ShowPerspectiveHandler.execute(ShowPerspectiveHandler.java:57)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:178)
at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:247)
at org.eclipse.ui.actions.PerspectiveMenu.runOther(PerspectiveMenu.java:376)
at org.eclipse.ui.actions.PerspectiveMenu$3.runWithEvent(PerspectiveMenu.java:130)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
at org.eclipse.equinox.launcher.Main.main(Main.java:1383)


 Comments   
Comment by Andrew Eisenberg [ 20/Jan/11 ]

Fixed.





[GRECLIPSE-968] NPE when console open - possibly just when shutting down eclipse Created: 19/Jan/11  Updated: 21/Feb/11  Resolved: 21/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: User Interface
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Minor
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Caused by: java.lang.NullPointerException
at org.codehaus.groovy.eclipse.ui.console.GroovyConsolePage$1.run(GroovyConsolePage.java:69)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
... 63 more



 Comments   
Comment by Andrew Eisenberg [ 21/Feb/11 ]

Fixed.





[GRECLIPSE-967] Breakpoint is set on wrong line number in Groovy Eclipse. Created: 19/Jan/11  Updated: 21/Jan/11  Resolved: 21/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Kyle Stewart Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, Eclipse Helios


Issue Links:
Related
is related to GRECLIPSE-888 [debug] Breakpoints set on the wrong ... Resolved
is related to GRECLIPSE-976 Ability to set method entry breakpoin... Resolved
Number of attachments : 0

 Description   

Not all the time, but frequently enough to be quite annoying, I can't set a breakpoint where I want to. I'll double click the gutter, and the breakpoint will flash on then off, and it will set the breakpoint somewhere else, lower in the code.

I'll be able to set breakpoints fine for certain parts of the code, but some sections of the code will exhibit the above described behavior.

When this happens I have to restart eclipse, or cut the code i want to set the breakpoint on, and paste it lower in the file. Sometimes I won't be able to set a breakpoint at all in the file, even if I move the code lower.

I saw issue http://jira.codehaus.org/browse/GRECLIPSE-888, but decided to file a separate issue because this happens for me even when I don't have any closure fields in the file.



 Comments   
Comment by Andrew Eisenberg [ 19/Jan/11 ]

Can you please attach a code snippet that exhibits this behavior?

Comment by Kyle Stewart [ 19/Jan/11 ]

It seems to happen on any of my groovy classes. Here is one of my classes I know it has happened on:

package org.kyle.common

import java.lang.reflect.*
import java.util.HashMap;
import java.util.Map;

import org.codehaus.groovy.ast.ClassNode;
import org.codehaus.groovy.ast.MethodNode;

class TypeUtil {
	static final Map PRIMITIVE_TO_WRAPPER = [:]
	static {
		PRIMITIVE_TO_WRAPPER.put(boolean.class, Boolean.class)
		PRIMITIVE_TO_WRAPPER.put(byte.class, Byte.class)
		PRIMITIVE_TO_WRAPPER.put(short.class, Short.class)
		PRIMITIVE_TO_WRAPPER.put(int.class, Integer.class)
		PRIMITIVE_TO_WRAPPER.put(long.class, Long.class)
		PRIMITIVE_TO_WRAPPER.put(float.class, Float.class)
		PRIMITIVE_TO_WRAPPER.put(double.class, Double.class)
		PRIMITIVE_TO_WRAPPER.put(char.class, Character.class)
	}

	
	
	
	static boolean isPrivate(Field f){
		return (f.getModifiers() & Modifier.PRIVATE) != 0
	}
	static boolean isStatic(Field f){
		return (f.getModifiers() & Modifier.STATIC) != 0
	}
	static boolean isProtected(Field f){
		return (f.getModifiers() & Modifier.PROTECTED) != 0
	}

	/**
	 * Just like Class.isAssignableFrom(), but does the right thing when considering autoboxing.
	 */
	static boolean isAssignableFrom(Class<?> to, Class<?> from) {
		Class<?> notPrimitiveTo = to.isPrimitive() ? PRIMITIVE_TO_WRAPPER.get(to) : to
		Class<?> notPrimitiveFrom = from.isPrimitive() ? PRIMITIVE_TO_WRAPPER.get(from) : from

		return notPrimitiveTo.isAssignableFrom(notPrimitiveFrom)
	}



	static Field getDeclaredField(Class c, String name){
		try{
			Field ret = c.getDeclaredField(name)
			return  ret
		}catch(NoSuchFieldException nfe){
			return null
		}
	}
	
	
	

	static def callMethodOrNull(def obj, String methodname, Object... args = []){
		def ret = null
		Class c = obj instanceof Class ? obj : obj.getClass()
		if(hasMethod(c, methodname)){
			ret = obj."$methodname"(*args)
		}
		return  ret
	}

	static boolean hasMethod(Class c, String name){
		//possibly use the metaclass like: respondsTo(Object obj, String name, Object[] argTypes)
		boolean ret = getMethod(c, name) != null
		return  ret
	}

	static Method getMethod(Class c, String name){
		List methods = getAllRealMethods(c)
		Method ret = methods.find { Method m -> m.getName() == name }
		return  ret
	}

	static List<Method> getAllRealMethods(Class c){
		List ret = getAllMethods(c).grep { Method m ->
			m.isSynthetic() == false && m.getName().contains('$') == false
		}
		return ret
	}
	static List<Method> getAllRealFields(Class c){
		List ret = getAllFields(c).grep { Field m ->
			m.isSynthetic() == false && m.getName().contains('$') == false
		}
		return ret
	}
	static List<Method> getAllMethods(Class c){
		//list is arranged starting with methods in subclass, ending with methods in superclass
		Class sup = c.getSuperclass()
		List<Method> ret = (c.getDeclaredMethods() as List) + (sup != null ? getAllMethods(sup) : [])
		return ret
	}
	static List<Field> getAllFields(Class c){
		//list is arranged starting with methods in subclass, ending with methods in superclass
		Class sup = c.getSuperclass()
		List<Field> ret = (c.getDeclaredFields() as List) + (sup != null ? getAllFields(sup) : [])
		return ret
	}
	
	
}
Comment by Andrew Eisenberg [ 21/Jan/11 ]

OK. I have a solution that I think is working here. Before determining if a line is a valid line to place a breakpoint, we walk the module node and sort all ASTNodes lexically. Then we can be certain that we won't visit nodes out of order.

I'm trying this out on your sample class and I am not seeing any breakpoints hopping locations. I'll need to test some more before I can be sure this is working.

Comment by Andrew Eisenberg [ 21/Jan/11 ]

I am now reasonably sure that this fixes your problem without breaking anything else. I just need to get the tests shaped up before committing.

Comment by Andrew Eisenberg [ 21/Jan/11 ]

Well, I am now getting an occasional exception when adding breakpoints:

Breakpoint does not have an associated marker.

This does not appear to affect behavior. It looks like some attributes of the breakpoint are being requested, but the underlying IResource Marker is not present. However, I can't isolate why this is happening.

Comment by Andrew Eisenberg [ 21/Jan/11 ]

Fixed with regression tests. If you see any more breakpoint issues, please raise a new bug for it and attach a code snippet to recreate the problem.





[GRECLIPSE-966] Instances of GroovyEditor are never collected (Memory Leak) Created: 19/Jan/11  Updated: 08/Mar/11  Resolved: 07/Mar/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Minor
Reporter: Stefan Sieber Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

Windows XP, Helios Service Release 1 Build id: 20100917-0705; Greclipse Version 2.1.2.xx-20110118-1300-e36


Attachments: Text File GroovyEditorGCReferences.txt    
Number of attachments : 1

 Description   

When opening and closing Groovy Scripts repeatedly,the instances of GroovyEditor are never collected.

In Version 2.1.1, this was very bad, because the GroovyEditor still had a reference to GroovyCompilationUnit which got quite big for larger scripts (tens of MB's).

In Version 2.1.2 GroovyEditor has no references to GroovyCompilationUnit anymore, which results in a small retained size of GroovyEditor. Therefore it is a minor bug.

GroovyEditor is not collected, because there are alive objects of class AllCleanUpsAction that are still referencing it. The attached text file contains a report of the Path to the GC root for Greclipse version 2.1.2.



 Comments   
Comment by Andrew Eisenberg [ 07/Mar/11 ]

Apologies for not responiding sooner. I think I see where the leak is coming from. We are replacing the AllCleanupsAction with our own variant of it. However, we are not calling dispose() on the original before we discard it. This is where I think the leak is coming from. I hope that this fix can make it into 2.1.2 final, but we are nearing the end of the release cycle. Since this is a memory, I'm hopeful that it will make it in.

Comment by Andrew Eisenberg [ 07/Mar/11 ]

Fix is committed and will be available for the 2.1.2 release. Thanks for reporting.

Comment by Stefan Sieber [ 08/Mar/11 ]

Thanks for fixing





[GRECLIPSE-965] No Groovy files can be compiled anymore Created: 19/Jan/11  Updated: 07/Apr/11  Resolved: 07/Apr/11

Status: Resolved
Project: GRECLIPSE
Component/s: Build and distribution
Affects Version/s: 2.1.2Release
Fix Version/s: 2.5.0Release

Type: Bug Priority: Blocker
Reporter: Rene Scheibe Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

All my Groovy classes don't compile anymore. It says:
"... cannot be resolved to a type"

Some errors I have seen:

  • Semikolons are required
  • parethesis are required when calling methods
  • method names including spaces are not supported

Even when removing the Groovy nature from the project it still tries to compile the Groovy files, resulting in the above errors.

Looks like it uses the Java compiler to compile Groovy classes.

I first have seen it in 2.1.2.xx-20110117-1900-e36 (but it could also be an ealier version). It's still there in 2.1.2.xx-20110118-1300-e36.



 Comments   
Comment by Rene Scheibe [ 19/Jan/11 ]

There is another strange thing. I removed the current Groovy Eclipse plugin version and reverted to an older one.

In "About Eclipse" -> "Installation Details" it shows the older version.
Under the "About Eclipse" -> "Groovy" button it shows the newer version.

Comment by Rene Scheibe [ 19/Jan/11 ]

After uninstalling the Groovy Eclipse plugin completely the "Groovy" button in "About Details" was still visible but in "Installation Details" the plugin is gone. Something screwed up Eclipse completely. So I started with a fresh Eclipse and the plugin seems to work even with the latest development version.

Comment by Erik De Rijcke [ 05/Mar/11 ]

Is there a workaround for this bug since I'm experiencing the same problem. Latest eclipse with both 2.1.0 and 2.1.1 groovy eclipse plugin seem to suffer from this bug.

Comment by Rene Scheibe [ 05/Mar/11 ]

I think it's some upgrade bug between two special versions. As I stated in my last post, starting with a fresh Eclipse solved the problem. Or try to uninstall the Groovy Eclipse plugin completely before installation. Also check and clean all artefacts of the plugin from Eclipse's plugin folder.

Comment by Andrew Eisenberg [ 05/Mar/11 ]

I've seen this before. I think there was a problem with installation. I think this is related to:

http://jira.codehaus.org/browse/GRECLIPSE-953

It appears to be a p2 error (Eclipse's provisioning system). The only work around that I know of is to uninstall Groovy-Eclipse and reinistall it again.

Comment by Michael Marson [ 07/Mar/11 ]

I experienced this issue over the weekend when upgrading Eclipse (Java EE flavor) from Helios SR1 to Helios SR2 via the "Check for Updates" option. No other updates were applied during that update. After upgrading, all groovy files that didn't use exact java-compatible syntax reported errors.

Further testing:

Wondering if the issue was the upgrade, I removed my full eclipse install and downloaded and installed Eclipse Helios SR2 (eclipse-jee-helios-SR2-win32.zip), and installed Groovy plugin via "Install New Software" (using URL http://dist.springsource.org/release/GRECLIPSE/e3.6/) and got the same errors. All groovy files that didn't use exact java-compatible syntax reported errors.

Finally, I remove Helios SR2 and reinstalled Helios SR1, reinstalled Groovy plugin as above and everything worked again.

So from what I am seeing there is an incompatibility between Helios SR2 and the current Groovy plugin (2.1.1.xx-20101215-2100-e36).

Comment by Andrew Eisenberg [ 07/Mar/11 ]

You are correct. Groovy-Eclipse 2.1.1 is not compatible with SR2. Please install the nightly build of Groovy-Eclipse. Since we are gearing up for 2.1.2, the nightly build is quite stable and is unlikely to change much between now and the release.

The reason for this problem has to do with the versioning of the plugins. We ship a patch for the JDT core plugin that overrides the existing plugin. The version number that we override is only the version for SR1. So, SR2 is deemed to be "newer" than the version that 2.1.1 provides and thus overwrites it. The latest nightly fixes this problem.

Update site:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

Comment by Andrew Eisenberg [ 07/Apr/11 ]

I think that we figured out all of the problems happening here, so I am closing this issue.





[GRECLIPSE-964] Grab annotation doesn't fetch Jedis library Created: 17/Jan/11  Updated: 09/Jan/13  Resolved: 05/Oct/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Dominik Leszyk Assignee: Andy Clement
Resolution: Not A Bug  
Labels: grab
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.10 (maverick); Eclipse 3.6.1 (not from packages); java version "1.6.0_23"


Number of attachments : 0

 Description   

Trying to obtain Jedis library (i.e. Redis client library - https://github.com/xetorthio/jedis) using following code doesn't work:

StartRedis.groovy
@Grab('redis.clients:jedis:1.3.0') 
import redis.clients.jedis.*

Jedis jedis = new Jedis("localhost")
jedis.set("foo", "bar");
println jedis.get("foo");

The 'new' keyword is marked with error. Tooltip says: 'Groovy:unable to resolve class Jedis'. After running this code using 'Run as Java Application' the exception appears:

xception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: No suitable ClassLoader found for grab
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
	at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:52)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:190)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:198)
	at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:163)
	at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
	at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:227)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:225)
	at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:153)
	at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:216)
	at groovy.grape.Grape.grab(Grape.java:131)
	at groovy.grape.Grape$grab.callStatic(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:48)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:165)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:173)
	at RedisConnect.<clinit>(RedisConnect.groovy)

Works smoothly from CLI.



 Comments   
Comment by Andy Clement [ 05/Oct/11 ]

You cannot run Grabby things as a Java Application like that. If you try it on the command line you get the same thing:

groovyc ThatScript.groovy
java ThatScript

will fail with the Grab error.

The classloader setup is only correct if you run it as a script. This will work on the command line:

groovy ThatScript.groovy

which you can also do in Eclipse by using the context menu RunAs>GroovyScript





[GRECLIPSE-963] Ignore warnings from code in linked source folders in grails projects Created: 17/Jan/11  Updated: 17/Jan/11  Resolved: 17/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Grails application typically have plugin dependencies. The code for these plugins may have warnings - the JDT compiler produces many more kinds of warning than typical javac so the plugin developer may not be aware of them. These plugin warnings make a mess when the grails app developer was just trying to consume the plugin and doesn't care about any issues within it.

If we can, we should ignore these warnings.



 Comments   
Comment by Andy Clement [ 17/Jan/11 ]

The easiest way to do this is to let the problems we created but then not add them to the resource if the resource is:

a) in a grails project
b) in a linked source folder in a grails project

and I'm only doing this for warnings right now. Errors will still come through.

The change can be made in ProblemHandler.handle(). We have a bit flag to identify a grails project.

This will mean warnings are hidden for 'other' linked source folders in the grails project, but that seems a very unusual setup. If that becomes an issue we will need to make our linked ones more identifiable. Yes, they have attributes but those attributes cannot be seen from where the decision is being made.

Comment by Andy Clement [ 17/Jan/11 ]

changes committed





[GRECLIPSE-962] commencingResolution fails when MultiplexingImportMatchLocatorParser involved Created: 17/Jan/11  Updated: 19/Jan/11  Resolved: 19/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Andy Clement Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I have a simple file FFF.groovy in a grails project:

package a.b.c

class FFF {
    
	int i; 
	
	private void foo() {}
}

if I select it in the package explorer and press Command+G (I was trying to do Alt+G, ALt+J but having mac keyboard issues, so pressed Command by accident!), I get (in the console):

BUG! exception in phase 'semantic analysis' in source unit 'FFF.groovy' commencingResolution failed: declaration found, but unexpectedly found no scope for a.b.c.FFF
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:952)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:574)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:550)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:527)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:165)
	at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1832)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1733)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1123)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1223)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1355)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:582)
	at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:144)
	at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:91)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug: commencingResolution failed: declaration found, but unexpectedly found no scope for a.b.c.FFF
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.commencingResolution(JDTResolver.java:578)
	at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1328)
	at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:164)
	at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:626)
	at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:680)
	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:943)
	... 16 more

The scope is missing because bindings haven't been built. Bindings haven't been built because in MatchLocator.parseAndBuildBindings() the mustResolve flag is false. This situation would be OK, but unfortunately sometime later some more code runs in MatchLocator.process()

        // GROOVY Start
	// Do not process non-Java files.  They use a separate delegated search
	if (LanguageSupportFactory.isInterestingSourceFile(new String(possibleMatch.getFileName()))) {
		possibleMatch.parsedUnit.resolve();
		return;
	}
	// GROOVY End

That call to resolve is what leads to the exception above because the scope is missing. If a buildTypeBindings is added ahead of the resolve:

this.lookupEnvironment.buildTypeBindings(possibleMatch.parsedUnit, null /*no access restriction*/);

then the exception goes away as the scope is correct by the time it is referenced. Not my code though so I don't know if this is the right thing to do and I don't know which tests to run to verify the change.



 Comments   
Comment by Andy Clement [ 18/Jan/11 ]

committed the change with a big try catch round it. Let's see if it gets through the tests.

Comment by Andy Clement [ 19/Jan/11 ]

Seems to fix things OK - user reported on greclipse-870 that it addressed his failing situation.





[GRECLIPSE-961] Exception in code conversion with array type nested in generic type Created: 14/Jan/11  Updated: 14/Oct/11  Resolved: 06/May/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.5.0Release

Type: Bug Priority: Critical
Reporter: Andrew Eisenberg Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following code snippet seems to have invalid slocs:

public List<int[]> x() { }

The following exception is thrown during reconciling:


java.lang.IllegalArgumentException
	at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java:2614)
	at org.eclipse.jdt.core.dom.ASTConverter.convertType(ASTConverter.java:3249)
	at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:518)
	at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:192)
	at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2781)
	at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1338)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.convert(CompilationUnitResolver.java:291)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1201)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:801)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:543)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:536)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:479)
	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:126)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:169)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$3.run(SelectionListenerWithASTManager.java:154)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

It looks like an array nested in a generic type is not handled properly with respect to source locations.



 Comments   
Comment by Andrew Eisenberg [ 14/Jan/11 ]

As expected, the following causes no problems:


public int[] x() {
	
}
public List<Integer> x2() {
	
}
Comment by Andrew Eisenberg [ 07/Mar/11 ]

The problem here is with GroovyCompilationUnitDeclaration.createTypeReferenceForArrayName().

There is a statement:

return TypeReference.baseTypeReference(ii, dim);

This statement is reached when there is an array reference contained inside of another type reference (generics, annotation, etc). The problem here is that the type reference is created, but its source location is not set.

Comment by Andrew Eisenberg [ 06/May/11 ]

Odd...seems to work now on both 1.7 and 1.8. Perhaps this was fixed with the upgrade to 1.7.10 and 1.8.0.





[GRECLIPSE-959] As I move a type between two packages, it gets an extra line inserted after the package statement Created: 12/Jan/11  Updated: 08/Feb/11  Resolved: 08/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Minor
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I created a type in package a.b.c, it looked like this:

package a.b.c

class C {
}

when I dragged it to package d.e.f it became

package d.e.f


class C {
}

as I move it back and forth, a new line is inserted each time.



 Comments   
Comment by Andrew Eisenberg [ 12/Jan/11 ]

Likely related to or a duplicate of GRECLIPSE-960.

Comment by Andrew Eisenberg [ 08/Feb/11 ]

Not a duplicate of GRECLIPSE-960. Fixed now.





[GRECLIPSE-958] Global AST doesn't seem to work Created: 11/Jan/11  Updated: 18/Jan/12  Resolved: 24/Nov/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: None
Fix Version/s: 2.6.1.M1

Type: Bug Priority: Major
Reporter: Daniel Henrique Alves Lima Assignee: Andy Clement
Resolution: Fixed  
Labels: wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse SDK; Version: 3.6.1; Build id: M20100909-0800
Groovy-Eclipse Feature 2.1.1.xx-20101215-2100-e36 (groovy 1.7.5)
jdk1.6.0_20; groovy-1.7.4


Attachments: File test_log.tar.bz2    
Number of attachments : 1

 Description   

I've tried to add log_code_guard.jar to the project classpath (the whole global AST is written in pure Java), but it wasn't enough. Am i missing something? It seems nothing is going on...

If i try to run using the command line, it "works" (i've inserted a bug
to be sure that the transformation was happening):

[daniel@anyhost test_log]$ groovy
-cp ./lib/log4j-1.2.15.jar:./lib/log_code_guard.jar:./bin
src/Bla.groovy
visitClass(): node Bla
log exp: LOGGER.debug(ok)
log method: debug
log method enabled: isDebugEnabled
parent if null
replacing...
1
Caught: groovy.lang.MissingMethodException: No signature of method:
org.apache.log4j.Logger.isDebugEnabled_() is applicable for argument
types: () values: []
Possible solutions: isDebugEnabled()
at Bla.main(Bla.groovy:9)

=====
Thread:

http://markmail.org/message/sb4greb5vorpgcif?q=global+ast+list:org%2Ecodehaus%2Egroovy%2Eeclipse-plugin-user



 Comments   
Comment by Andrew Eisenberg [ 21/Feb/11 ]

Groovy Event trace console is now available and shows AST Transforms.

Comment by Andy Clement [ 24/Nov/11 ]

Looks to have been fixed at some point, behaves the same on command line and in eclipse. event console reports transform ran ok:

Ast Transforms : 12:36:04 Global transform org.codehaus.groovy.grails.plugins.log_code_guard.ast.CodeGuardTransformation on /Users/aclement/Downloads/test_log/src/Bla.groovy = 10ms





[GRECLIPSE-957] extract method not behaving quite right and including a return value where none is required Created: 11/Jan/11  Updated: 09/Feb/11  Resolved: 09/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Refactoring
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Minor
Reporter: Andy Clement Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Number of attachments : 0

 Description   

I have this controller:

 def list = {
        params.max = Math.min(params.max ? params.int('max') : 10, 100)
	Thread.sleep(2000)
        [albumInstanceList: Album.list(params), albumInstanceTotal: Album.count()]
 }

I select the whole section 'Thread.sleep(2000)' and then refactor extract method to a method called 'delay', the code becomes this:

    def list = {
        params.max = Math.min(params.max ? params.int('max') : 10, 100)
		params = delay()
        [albumInstanceList: Album.list(params), albumInstanceTotal: Album.count()]
    }

    private Map delay() {
		Thread.sleep(2000)
		return params
    }

I wasn't expecting a return value in the method signature and return value at the end of the method.



 Comments   
Comment by Andrew Eisenberg [ 09/Feb/11 ]

Fixed along with the changes for GRECLIPSE-984.

Comment by Andrew Eisenberg [ 09/Feb/11 ]

Fixed along with the changes for GRECLIPSE-984.





[GRECLIPSE-956] Groovy methods and tokens are highlighted in black Created: 11/Jan/11  Updated: 04/Mar/11  Resolved: 21/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: None
Fix Version/s: 2.1.2Release

Type: Bug Priority: Minor
Reporter: Steven Sproat Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

2.6.31-22-generic #70-Ubuntu SMP Wed Dec 1 23:48:17 UTC 2010 x86_64 GNU/Linux – Ubuntu 9.10
STS 2.5


Attachments: File eclipse-test.pref     PNG File Screenshot-2.png    
Number of attachments : 2

 Description   

I just updated to the latest version, 2.1.2.xx-20110107-0900-e36

Now all my groovy tokens, such as the equals in variable assignments, braces, parenthesis, brackets, << for HashMap shifting as well as method calls (including definitions) are highlighted in black. I cannot find an option to change this colour.

I use a black background so I can't read my code

Another issue I've noticed is that items "def"'d are coloured in this dark purple that doesn't work with my black background. I can't find an option to change this colour either.

Attached is a screenshot and my preferences file (hopefully my colours came through!)



 Comments   
Comment by Andrew Eisenberg [ 11/Jan/11 ]

Yes, we have been making some changes to syntax highlighting in the Groovy Editor. This can be tweaked in Preferences -> Java -> Editor -> Syntax Coloring.

Method and field declarations and references now follow the Java preferences.

Groovy keyword (such as def) and groovy operator highlighting can be tweaked in the Groovy -> Editor preference page.

Let me know if this is sufficient for you. Perhaps we should be more explicit on the preferences page about what these settings actually do.

Comment by Steven Sproat [ 11/Jan/11 ]

Hi Andrew,

First up - many thanks for the excellent plugin.

As a test, I changed my Java preferences for declared method's colour, but this preference was not used in a Groovy file. I tried copying my Java colour preferences too, to no avail.

Let me know if I can post more detail/help in any other way.

Comment by Steven Sproat [ 11/Jan/11 ]

I think I've fixed this. I re-edited the preferences in the Groovy colours dialog, so I clicked each colour to pop up the colour picker, and just hit okay, and it has reset it.

My code is finally readable, hurrah!
Think this case may be closed, due to user error. Thanks.

Comment by Andrew Eisenberg [ 11/Jan/11 ]

Thanks for getting back to me. I will be doing a full review of all the dialogs and text before the final release. This should avoid some similar confusion for other users.

Comment by Steven Sproat [ 24/Jan/11 ]

Hi Andrew,

I'm still having an issue where my any method calls/definitions are coming through as black. I've enabled the
Java -> Editor -> Syntax Coloring -> Java -> Method Declarations preference and set the colour to red. I then went to the groovy editor colour selection page and "copy java color preferences".

After hitting apply, no difference was made. I opened a Java file and the method definitions there was red.

It's odd, I previously reported that I had fixed this but the next time I restarted Eclipse it was still broken.

Comment by Andrew Eisenberg [ 24/Jan/11 ]

OK. Reopening this and I'll have a look at the problem.

Comment by Andrew Eisenberg [ 08/Feb/11 ]

Is this still a problem for you?

I have tried to reproduce, but I cannot. Colors for methods and fields are in the Java syntax coloring page. You do not need to change anything in the Groovy Editor page for this to work. However, you may need to close and re-open your groovy files.

Comment by Andrew Eisenberg [ 08/Feb/11 ]

Is this still a problem for you?

I have tried to reproduce, but I cannot. Colors for methods and fields are in the Java syntax coloring page. You do not need to change anything in the Groovy Editor page for this to work. However, you may need to close and re-open your groovy files.

Comment by Andrew Eisenberg [ 21/Feb/11 ]

Trying to clean up issues for the upcoming milestone release. Since I haven't heard back from my previous comments, I am assuming that this is working right now. Feel free to reopen if you are still experiencing a problem.

Comment by Steven Sproat [ 21/Feb/11 ]

Hi Andrew,

So very sorry! I somehow fixed this problem by just re-installing STS. I apologise for not getting back on the issue.





[GRECLIPSE-955] organized import of extends is removed Created: 10/Jan/11  Updated: 11/Jan/11  Resolved: 11/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jon Assignee: Unassigned
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse 3.6 mac osx 10.6 Version: Helios Service Release 1
Build id: 20100917-0705 Groovy-Eclipse plugin

Version: 2.1.2.xx-20110107-0900-e36
Groovy version: org.codehaus.groovy


Number of attachments : 0

 Description   

import com.Foo

class Bar extends Foo {}

when I organize imports, the import is removed.



 Comments   
Comment by Andrew Eisenberg [ 10/Jan/11 ]

I cannot reproduce this one either. Can you attach a failing project?

Also, apologies for the silly questions, but since the behavior you are seeing is odd, I need to ask them:

  1. are you opening the file in a Groovy editor or a Java editor?
  2. is your groovy file on the build path of your project?
  3. are there any other errors in your files or in your project?
Comment by Jon [ 11/Jan/11 ]

You know what, I'm working with a @#$@#$@ grails project that I didn't start and I'm now figuring out that it is setup in a bit of a mess. Let me clean that up and if I still see errors, I'll file some new issues. Thanks for the fast response.

Comment by Jon [ 11/Jan/11 ]

invalid

Comment by Andrew Eisenberg [ 11/Jan/11 ]

Not a problem. Please create new bugs if you find anything.





[GRECLIPSE-954] organize imports has problems with static members Created: 10/Jan/11  Updated: 11/Jan/11  Resolved: 11/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: Editor
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Jon Assignee: Andrew Eisenberg
Resolution: Not A Bug  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eclipse 3.6 mac osx 10.6 Version: Helios Service Release 1
Build id: 20100917-0705 Groovy-Eclipse plugin

Version: 2.1.2.xx-20110107-0900-e36
Groovy version: org.codehaus.groovy


Number of attachments : 0

 Description   

import org.apache.commons.logging.LogFactory

class CustomerBill

{ def static log = LogFactory.getLog(getClass()) }

If I organize imports on that file, then the import is removed.



 Comments   
Comment by Andrew Eisenberg [ 10/Jan/11 ]

I just tried this and cannot reproduce on my system. Can you attach a full project that reproduces this problem?

Comment by Jon [ 11/Jan/11 ]

invalid





[GRECLIPSE-953] Installing groovy-eclipse 2.1.1 into Eclipse helios SR1 makes java functionality unavailable Created: 09/Jan/11  Updated: 29/Sep/11  Resolved: 29/Sep/11

Status: Resolved
Project: GRECLIPSE
Component/s: None
Affects Version/s: 2.1.1Release
Fix Version/s: 2.5.2.Release

Type: Bug Priority: Major
Reporter: AdamFinlayson Assignee: Andrew Eisenberg
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP , Dell Latitude E4300


Attachments: File bundles.info     Text File eclipseConfiguration.txt    
Number of attachments : 2

 Description   

I have installed a plain installation of Eclipse Helios SR1 ( eclipse.buildId=M20100909-0800).
I opened an empty workspace with java perspective to verify the installation was working ok.

I then use the update manager to install version 2.1.1.xx-20101215-2100-e36 of the groovy plugin from http://dist.springsource.org/release/GRECLIPSE/e3.6/
Restarted eclipse after update and loaded blank workspace again
Java perspective has disappeared and not able to do any java functions. ie. can't open java perspective, can't create new java project or file.

Looking in bundles.info there is no org.eclipse.jdt.core entry at all.

See attached files for eclipseConfiguration and bundles.info after update



 Comments   
Comment by Andrew Eisenberg [ 09/Jan/11 ]

This problem usually happens because your install directory is read only. Is your Eclipse installed in C:\Program Files?

It is not possible to install groovy-eclipse into a read-only eclipse install? See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=332158

Comment by AdamFinlayson [ 10/Jan/11 ]

I installed eclipse into C:\Developer\software\helios-test so not under any protected directories at all.
It's on a windows system and when unzip eclipse it does seem to make the directories appear read only when look in properties on a directory but doesn't restrict writing to the directory.
I tried reverting the install and then making all directories under helios-test non read only, then installing plugin again but same problem occurred.
It seems to download the jars to the plugins directory fine as I can see a new version of the jdt.core jar gets downloaded. This doesn't appear in the bundles.info file though and even if I manually add to the bundles.info doesn't help the java functionality re-appear.

Comment by Andrew Eisenberg [ 11/Jan/11 ]

I just raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=334012 to track this issue. It appears to be a p2 problem.

You said that you edited your bundles.info file. What exactly did you add to it? It should look something like this:

org.eclipse.jdt.core,<VERSION>,plugins/org.eclipse.jdt.core_<VERSION>.jar,4,false

Where <VERSION> is the version of your patched jdt core jar in your installs directory. It should also be sorted properly by alphabetical order.

Comment by AdamFinlayson [ 11/Jan/11 ]

I added the line
org.eclipse.jdt.core,3.6.1.xx-20101215-2100-e36,plugins/org.eclipse.jdt.core_3.6.1.xx-20101215-2100-e36.jar,4,false

Just above the line
org.eclipse.jdt.core.manipulation,1.3.0.v20100520-0800,plugins/org.eclipse.jdt.core.manipulation_1.3.0.v20100520-0800.jar,4,false
in the bundles.info

I've managed to get it to work ok for me this morning though by installing from the zip download of version archive-2.1.1.xx-20101215-2100-e36.zip rather than from the update site.

Looking at the installation when I used the update site it looks like the jar org.eclipse.jdt.core_3.6.1.xx-20101215-2100-e36.jar hadn't fully downloaded and had been truncated (was smaller than when I installed from the zip file). I think the installation manager must have then removed the entry from bundles.info when it found a corrupted jar file. Didn't see any errors to say this though.
I suspect the proxy I'm behind might have caused the truncation.

All working now though.

Comment by Andrew Eisenberg [ 11/Jan/11 ]

Thanks for the update. It's good to know that you have gotten it working. And it's also good to know a potential fix in case other people have the same problem. I'm surprised that p2 didn't complain with any errors for that corrupted jar file.

I'm leaving this issue open for now until I hear back from the p2 team.

Comment by Mike Kilgore [ 13/Jan/11 ]

I am having the exact same problem with losing java features, specifically hover is the one I noticed. I am running on OS X 10.6.6 Eclipse 3.6. This only appears to be happening with the latest 2.1.1 update. I have full access to write files in the install directory and I am not behind a proxy.

While my preference is to be using the update site, I will also try the workaround above using the zip version.

Thanks,

Comment by Andrew Eisenberg [ 13/Jan/11 ]

Can you tell if the org.eclipse.jdt.core jar from the update site is truncated?

Comment by Mike Kilgore [ 14/Jan/11 ]

I have not tried using the zip file yet, but the size of the jdt.core jar files are the same 4.5 mb. It does not look like truncation is the issue here

Comment by Mike Kilgore [ 18/Jan/11 ]

I have also tried the the archive file and had the same results. This is now looking like a different problem from the original report. It is easy to reproduce the problem where combined hovers stop working in the eclipse editor only if I have the Groovy-Eclipse Feature installed. This happens on either my Windows or OS X machine. The other plugins I have installed are:
Maven
Subclipse 1.6.x

Comment by Mike Kilgore [ 18/Jan/11 ]

One additional note - Java combined hovers work with no problem when I load the archive version of 2.1.0. This problem appears only when loading 2.1.1

Comment by Andrew Eisenberg [ 19/Jan/11 ]

@Mike,

What exactly is the problem that you are seeing? Are you only seeing a problem with hovers and does you still have Java functionality after the problematic install?

We did make a change to the way that hovers work in 2.1.1. So, can you please explain exactly what is working for you and what is not?

Comment by Mike Kilgore [ 19/Jan/11 ]

Andrew,

I apologize for not being more clear. First the only problem I have currently is hovers, no other problems with java functionality.

The specific problem is this

  • when the plugin is not installed, and I am in debugging mode (hovers set to combined) hovering over an active variable show the current value of that variable. This is standard behavior.
  • when the plugin is installed, hovering over the variable, again in debugging perspective does not show the variable value the hover appears to default to javadoc only view.

Removing the plugin corrects the issue.

Please let me know if I can provide any additional information.

Comment by Mike Kilgore [ 19/Jan/11 ]

Andrew,

Looking at this a bit more I think I see where the problem could be... When the plugin is installed the second choice in the java editor hover is now 'Groovy Information Hover'. As I understand the combined choice it attempts to identify the best hover choice looking down that list. The 'best' choice is Variable Values' while in debugging mode (at least that is my best choice). I can manually select Variable Value and it works as expected. Could the addition of Groovy Information Hover alter the way 'Combined' works?

Comment by Andrew Eisenberg [ 19/Jan/11 ]

You are describing a very different issue from the installation problems above.

Are you seeing this behavior in Java code, or in Groovy code only? It is possible that this is coming from the Groovy Information Hover. I am currently on vacation and I am not able to look at this. However, could you raise a new bug for this and I will get to it as soon as I can?

Comment by Mike Kilgore [ 25/Jan/11 ]

The hover problem happens when debugging java code... You are correct this is a different issue. I have opened a new bug GRECLIPSE-978 to track it.

Comment by Andrew Eisenberg [ 25/Jan/11 ]

@Mike

Thanks. I am going to leave this issue open since we have not actually fixed the root of it (even though we have a workaround). I'll comment on the new issue.

Comment by Andrew Eisenberg [ 13/Jun/11 ]

Decreasing priority since we know of a workaround and there is not much we can do to actually fix this.

Comment by Andrew Eisenberg [ 29/Sep/11 ]

Resolving this issue now. There is not much else we can do. It is easy enough to recognize and diagnose the problem and then describe the workaround





[GRECLIPSE-952] Incorrect error message for (bad) Groovy file Created: 05/Jan/11  Updated: 04/Mar/11  Resolved: 05/Jan/11

Status: Resolved
Project: GRECLIPSE
Component/s: Compiler Integration
Affects Version/s: 2.1.1Release
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Kris De Volder Assignee: Unassigned
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STS 2.5.2.RC4


Number of attachments : 0

 Description   

Inside a grails project I had the following code

Spackage sharedwithouteclipsefiles

class SongController {

    def scaffold = Song
}

Note the extra "S" in from of "package" (accidentally added there).

Instead of an error near the "Spackage" what I get is a rather unexpected error of "Duplicate class definition".

Description	Resource	Path	Location	Type
Groovy:Invalid duplicate class definition of class SongController : The source /SharedWithoutEclipseFiles/grails-app/controllers/sharedwithouteclipsefiles/SongController.groovy contains at least two definitions of the class SongController.	SongController.groovy	/SharedWithoutEclipseFiles/grails-app/controllers/sharedwithouteclipsefiles	line 3	Java Problem
The type SongController is already defined	SongController.groovy	/SharedWithoutEclipseFiles/grails-app/controllers/sharedwithouteclipsefiles	line 3	Java Problem


 Comments   
Comment by Kris De Volder [ 05/Jan/11 ]

OK, as Andrew just explained to me. This is a Groovy "problem".

Because there is no "package" at the start Groovy starts reading this as a Script, with an implicit "SongController" class wrapped around it, so that is why there is a "duplicate" class definition.

Since the same thing happens with commandline groovyc this is not a Greclipse issue but a quirk in the groovy language.





[GRECLIPSE-950] Type inferencing of Groovy Enum fields not working Created: 04/Jan/11  Updated: 04/Mar/11  Resolved: 04/Feb/11

Status: Resolved
Project: GRECLIPSE
Component/s: Inferencing Engine
Affects Version/s: 2.1.1Release
Fix Version/s: 2.1.2Release

Type: Bug Priority: Major
Reporter: Andrew Eisenberg Assignee: Andy Clement
Resolution: Fixed  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
enum G {
  First, Second, Third
}
G.First

Hovering over First in G.First will show G instead of First. This means that all operations such as search, semantic highlighting and navigation for the enum field is broken.



 Comments   
Comment by Andy Clement [ 04/Feb/11 ]

believe fixed by the recent enum changes. At least the symptoms described in this bug no longer occur. Hovering over G.First shows G.First





Generated at Fri May 22 16:21:54 CDT 2015 using JIRA 6.1.6#6162-sha1:7af547ce7c84dbb7c1e345a65437ed7b85efffa2.